[dart-misc] Backstory for generalized tearoff removal?

[Alec Henninger]

"The language team has decided the generalized tear-off feature looks like
it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518

How come?

(That is, from a likes-to-hear-about-language-design-experiences more than
an oh-no-don't-remove-this-feature-please point of view.)

Cheers.

[Joao Pedrosa]

Hi,

I think some of the Dart team are on vacation to be able to answer this.

From what I have seen of the discussions about it, it seems that compiling
Dart to JavaScript has taken precedence, and this feature was never fully
implemented in the Dart to JavaScript compilers.

I think this feature lent itself to an advanced use-case of constructors,
and
the Dart team has said before that constructors are some of the most
complicated features of the language. Add to it that Dart has been evolving
in the direction of static types while still supporting dynamic types as a
backup
and it becomes more complicated.

It seems that the feature was at least partially implemented on the Dart VM
itself. But the Dart VM has since seen its use be relegated to running Dart
tools and nowadays Flutter, and supporting just the Dart VM became more
unnecessary. Flutter does not need the entire VM when being deployed, and
in Flutter they have found out that AoT can be useful for them on Android
and iOS. And AoT strips the VM bare for deployment. Which is probably to
say that the Dart VM will not be shipping fully to all possible devices
either.

The Dart team seems to be trying to balance the needs of Flutter, Dart to
JavaScript and "sound typing." They may have stopped developing the
language in earnest and may be trying to cut some corners these days. I
haven't seen much activity from Gilad Bracha who helped to make the
language features more thorough. The team may be reduced to being more
practical and to serving Google's shorter term needs.

Cheers,
Joao

Post by Alec Henninger
"The language team has decided the generalized tear-off feature looks
like it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518
How come?
(That is, from a likes-to-hear-about-language-design-experiences more
than an oh-no-don't-remove-this-feature-please point of view.)
Cheers.
--
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

[kc]

I think the lang team are thinking about removing 'new' or making it
optional. So a use case goes. Also, I think they want to bundle up lang
changes into a Dart 2.0 (which is sensible).

Personally I liked the idea of explicit syntax for tear-offs - even if
unfamiliar. But '#' was a tad heavy and used a valuable symbol.

K.

Post by Alec Henninger
"The language team has decided the generalized tear-off feature looks
like it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518
How come?
(That is, from a likes-to-hear-about-language-design-experiences more than
an oh-no-don't-remove-this-feature-please point of view.)
Cheers.

['Erik Ernst' via Dart Misc]

There is no particular problem compiling generalized tear-offs to
JavaScript, but given that this feature hasn't been implemented on other
platforms than the vm, and given that the semantics may be confusing (just
one example: why should the tear-off of a getter be a method that takes an
empty argument list, rather than an actual first class getter?) we decided
to take one step back at this point. For constructor tear-offs there
shouldn't be anything particularly tricky in relation to typing, and I
expect that we will support them (just not with a `#`). But we haven't
decided, so there are no promises. ;)

Post by kc
I think the lang team are thinking about removing 'new' or making it
optional. So a use case goes. Also, I think they want to bundle up lang
changes into a Dart 2.0 (which is sensible).
Personally I liked the idea of explicit syntax for tear-offs - even if
unfamiliar. But '#' was a tad heavy and used a valuable symbol.
K.

Post by Alec Henninger
"The language team has decided the generalized tear-off feature looks
like it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518
How come?
(That is, from a likes-to-hear-about-language-design-experiences more
than an oh-no-don't-remove-this-feature-please point of view.)
Cheers.

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

['Florian Loitsch' via Dart Misc]

Another take on the change:

The most important reasons for `#` were:
- works for constructors
- works for getters/setters.
- makes it easier to not accidentally take a tear-off, instead of calling a
function.

The third point only works, if we disallow the current syntax.

The drawbacks were:
- another way of doing things (unless we deprecate the old tear-off syntax,
`o.f`).
- heavy on the eyes.
- strongly different semantics for `o.f()` and `(o.f)()`, when `f` is a
field.
- doesn't work for global functions (since `#foo` is a symbol, and not the
tear-off of the global `foo`).

We want to make constructors and static functions more similar (see
"optional new") and allow constructor tear-offs with `A.named` or `A.new`.
We believe that tearing off getters/setters is not important enough, and we
would prefer to give shorthand syntax for simple functions (which would
apply in many more other cases). For example: `=> $.x` instead of `(o) =>
o.x`. (The syntax is not final yet, but we are working on it).
Since we move towards a world where static types are more common, it's now
much harder to accidentally tear a function off without intending to. The
type system would catch it almost all the time.

We believe that the new approach would get rid of all the drawbacks while
still giving the best of the `#` syntax. Since the `#` wasn't widely
implemented we also hope that the change in direction isn't too breaking.

Just as a warning: while we have a pretty good idea of how we want to move
forward here, we probably won't be able to implement all of these features
in the near future. Things will hopefully start moving a bit faster once we
have a finished our refactoring to take advantage of the kernel IR.

Post by 'Erik Ernst' via Dart Misc
There is no particular problem compiling generalized tear-offs to
JavaScript, but given that this feature hasn't been implemented on other
platforms than the vm, and given that the semantics may be confusing (just
one example: why should the tear-off of a getter be a method that takes an
empty argument list, rather than an actual first class getter?) we decided
to take one step back at this point. For constructor tear-offs there
shouldn't be anything particularly tricky in relation to typing, and I
expect that we will support them (just not with a `#`). But we haven't
decided, so there are no promises. ;)
I think the lang team are thinking about removing 'new' or making it
optional. So a use case goes. Also, I think they want to bundle up lang
changes into a Dart 2.0 (which is sensible).
Personally I liked the idea of explicit syntax for tear-offs - even if
unfamiliar. But '#' was a tad heavy and used a valuable symbol.
K.
"The language team has decided the generalized tear-off feature looks
like it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518
How come?
(That is, from a likes-to-hear-about-language-design-experiences more than
an oh-no-don't-remove-this-feature-please point of view.)
Cheers.
--
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
--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984 <28%2086%2069%2084>
--
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

[Greg Lowe]

`=> $.x` instead of `(o) => o.x`

Thumbs up! Will be great to have a shorthand to use with map.

- works for constructors
- works for getters/setters.
- makes it easier to not accidentally take a tear-off, instead of calling
a function.
The third point only works, if we disallow the current syntax.
- another way of doing things (unless we deprecate the old tear-off
syntax, `o.f`).
- heavy on the eyes.
- strongly different semantics for `o.f()` and `(o.f)()`, when `f` is a
field.
- doesn't work for global functions (since `#foo` is a symbol, and not the
tear-off of the global `foo`).
We want to make constructors and static functions more similar (see
"optional new") and allow constructor tear-offs with `A.named` or `A.new`.
We believe that tearing off getters/setters is not important enough, and
we would prefer to give shorthand syntax for simple functions (which would
apply in many more other cases). For example: `=> $.x` instead of `(o) =>
o.x`. (The syntax is not final yet, but we are working on it).
Since we move towards a world where static types are more common, it's now
much harder to accidentally tear a function off without intending to. The
type system would catch it almost all the time.
We believe that the new approach would get rid of all the drawbacks while
still giving the best of the `#` syntax. Since the `#` wasn't widely
implemented we also hope that the change in direction isn't too breaking.
Just as a warning: while we have a pretty good idea of how we want to move
forward here, we probably won't be able to implement all of these features
in the near future. Things will hopefully start moving a bit faster once we
have a finished our refactoring to take advantage of the kernel IR.
On Mon, Nov 7, 2016 at 3:16 PM 'Erik Ernst' via Dart Misc <

Post by 'Erik Ernst' via Dart Misc
There is no particular problem compiling generalized tear-offs to
JavaScript, but given that this feature hasn't been implemented on other
platforms than the vm, and given that the semantics may be confusing (just
one example: why should the tear-off of a getter be a method that takes an
empty argument list, rather than an actual first class getter?) we decided
to take one step back at this point. For constructor tear-offs there
shouldn't be anything particularly tricky in relation to typing, and I
expect that we will support them (just not with a `#`). But we haven't
decided, so there are no promises. ;)

Post by kc
I think the lang team are thinking about removing 'new' or making it
optional. So a use case goes. Also, I think they want to bundle up lang
changes into a Dart 2.0 (which is sensible).
Personally I liked the idea of explicit syntax for tear-offs - even if
unfamiliar. But '#' was a tad heavy and used a valuable symbol.
K.

Post by Alec Henninger
"The language team has decided the generalized tear-off feature looks
like it won't work as well as originally hoped" from
https://github.com/dart-lang/sdk/issues/27518
How come?
(That is, from a likes-to-hear-about-language-design-experiences more
than an oh-no-don't-remove-this-feature-please point of view.)
Cheers.

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984
--
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