It looks like Dart is sticking with lhs type annotations with a tweak re function type syntax:My suggestion is that maybe Call (or Callable) would be better than Function. Matches the 'call' method on Callable objects and indicates not only functions but tear-off methods/constructors. Also short.
The github issue mentions putting the return type of functions/methods on the rhs. This is like fidl - the Fuchsia Interface Definition Language. Given the centrality of Flutter/Fuchsia to Dart going forward is there a case for synchronising the Dart syntax and fidl where possible. Lessen the friction or mismatch.
--K.
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
On Tue, May 16, 2017 at 1:15 PM kc <kevin...@gmail.com> wrote:It looks like Dart is sticking with lhs type annotations with a tweak re function type syntax:My suggestion is that maybe Call (or Callable) would be better than Function. Matches the 'call' method on Callable objects and indicates not only functions but tear-off methods/constructors. Also short.I'm not sure that distinction is necessary. Once a method (or constructor) is torn-off, it is effectively a function.I don't buy that they are shorter either. If we compare "Func" vs "Call", and "Function" vs "Callable", then "Function" (or "Func") is at least as short.Fwiw,
"Call" doesn't reflect the type of the object. (It's not a "call" object).
The github issue mentions putting the return type of functions/methods on the rhs. This is like fidl - the Fuchsia Interface Definition Language. Given the centrality of Flutter/Fuchsia to Dart going forward is there a case for synchronising the Dart syntax and fidl where possible. Lessen the friction or mismatch.The issue wants to move the type variable declaration more to the left. Something like: `<T> T Function()` instead of `T Function<T>()`.I don't see any easy way to do this. We discussed (at length) moving the return-type to the right (which would incidentally solve the issue), but ended up with the current syntax, because the syntax didn't fit nicely the language and came with other problems (especially, once we add nullability).
On Tuesday, May 16, 2017 at 12:32:51 PM UTC+1, Florian Loitsch wrote:On Tue, May 16, 2017 at 1:15 PM kc <kevin...@gmail.com> wrote:It looks like Dart is sticking with lhs type annotations with a tweak re function type syntax:My suggestion is that maybe Call (or Callable) would be better than Function. Matches the 'call' method on Callable objects and indicates not only functions but tear-off methods/constructors. Also short.I'm not sure that distinction is necessary. Once a method (or constructor) is torn-off, it is effectively a function.I don't buy that they are shorter either. If we compare "Func" vs "Call", and "Function" vs "Callable", then "Function" (or "Func") is at least as short.Fwiw,'Call' eyeballs well imo and stands out. 'Func' also stands out vs 'Function'. Though maybe not as aesthetic."Call" doesn't reflect the type of the object. (It's not a "call" object).Sure. I get that.The github issue mentions putting the return type of functions/methods on the rhs. This is like fidl - the Fuchsia Interface Definition Language. Given the centrality of Flutter/Fuchsia to Dart going forward is there a case for synchronising the Dart syntax and fidl where possible. Lessen the friction or mismatch.The issue wants to move the type variable declaration more to the left. Something like: `<T> T Function()` instead of `T Function<T>()`.I don't see any easy way to do this. We discussed (at length) moving the return-type to the right (which would incidentally solve the issue), but ended up with the current syntax, because the syntax didn't fit nicely the language and came with other problems (especially, once we add nullability).OK. Devs are becoming increasingly aware of FuchsiaOS and the more Dart seems first class and orthogonal to Fuchsia the better.