gbracha / generalizedtearoffs Goto Github PK

The definition of closurization of, say, an operator is (a){return u m a;} (where m is the operator).
This loses the static return type, and needs extra specification to put it back in.
If the definition was instead (a)=>u m a then the return type comes automatically because the static return type of a (..)=>expr function is the static type of expr.

When tearing-off a non-existing member of an object, the noSuchMethod of the object is called, but with insufficient information for the method to recognize it as a tear-off.

The spec says:

Otherwise, a new instance im of the predefined class Invocation is created, such that :

• If m is a setter name, im.isSetter evaluates to true; otherwise im.isMethod evaluates to true.
• im.memberName evaluates to ’m’.
• im.positionalArguments evaluates to the value of const [].
• im.namedArguments evaluates to the value of const {}.

This means that tearing off a getter and a method are indistinguishable from calling a method.
This makes it impossible for the object to emulate the tear-off with noSuchMethod.
A method tear-off like o#foo should be emulated by returning a function, but calling the method o.foo() should execute the emulated function instead. The two accesses have the same Invocation instance, and cannot be distinguished.

Changing the invocation to im.isGetter instead won't fix that, because it breaks getter access/tear-off instead.

Consider this sequence of events:

Day one:

class Foo {
  String get awesome => 'awesome';
}

main() {
  var f = new Foo();
  print(f.awesome);
}

On Day two, I change the getter to a method:

class Foo {
  String awesome() => 'awesome';  // CHANGED
}

main() {
  var f = new Foo();
  print(f.awesome);  // DID NOT CHANGE
}

Oops! Syntactically, this is a valid program. But the intent changed and there's no way for my tools to warn me. This happened to me during a lengthy refactoring, and I was surprised that changing from a getter to a method left my code in a weird/broken state.

So, +1 for a more explicit syntax for closurization.

I hope we can build tools that will minimize the older use of the "implicit closurization" and suggest the new syntax to developers. Maybe even one day we can remove the implicit closurization syntax from the language. :)

I'd like there to be a short-hand for (x) => x.foo.

Assuming a symbol other than # is used for tear offs, i.e. perhaps :, thus removing the conflict with symbols, then (x) => x.foo could then be written as :foo.

This is useful with map. i.e. list.map((x) => x.foo) becomes list.map(:foo).

Another possibility is # could still be used and symbols could be made callable, so that #foo is also equivalent to (x) => x.foo when passed as a function.

Full example:

class Foo {
    Foo(this.bar);
    int bar;
}

List<Foo> foos = [new Foo(1), new Foo(2), new Foo(3)];

// :bar is identical to (x) => x.bar
List<int> bars = foos.map(:bar); // [1, 2, 3]

Maybe an alternative separator should be used, e.g. '::'

var method = MyClass::myMethod;

On the other hand, maybe one could consider tear-offs as symbols with a namespace...