Dart 2 - Function type syntax

499 views
Skip to first unread message

kc

unread,
May 16, 2017, 7:15:54 AM5/16/17
to Dart Misc
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.

Florian Loitsch

unread,
May 16, 2017, 7:32:51 AM5/16/17
to mi...@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).

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.

kc

unread,
May 16, 2017, 7:47:59 AM5/16/17
to Dart Misc
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.

K.

Florian Loitsch

unread,
May 16, 2017, 7:52:45 AM5/16/17
to mi...@dartlang.org
On Tue, May 16, 2017 at 1:48 PM kc <kevin...@gmail.com> wrote:
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.

I agree. However, I think it's more important to have the semantics right. For example, Fidl (or at least Mojo) has nullable types. It's much more important to get feature parity there, than with the syntax. Converting syntax from one to the other is trivial.

Fwiw, at some point I worked on integrating Mojo into Dart [0] [1], to make it the preferred cross-isolate communication mechanism. I didn't have enough time to really finish it, but I would like to eventually do the same for Fidl.

Reply all
Reply to author
Forward
0 new messages