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

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

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.

[Erik Ernst]

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. ;)

--

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.

--

Erik Ernst  -  Google Danmark ApS

Skt Petri Passage 5, 2 sal, 1165 København K, Denmark

CVR no. 28866984

[Florian Loitsch]

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.

[Greg Lowe]

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

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