Error for using a lambda in a setter

[alan-knight]

The analyzer recently changed so that

set foo(x) => _foo = x;

is a type error. It can't cause anything to go wrong, but it's a bit confusing. But it's also a severe error that prevents compilation, so the couple of occurrences of this in the Intl package prevent Angular from compiling. This seems overkill for something that can never be a runtime problem.

[zoechi]

See also #25228

[jmesserly]

@vsmenon -- thoughts on this one?

it was caused by #25228. We'll also infer "void" as the setter return type in strong mode (Which was itself a user request. It catches incorrect "return", which means you can leave off the "void" with no change in the type system. Leaving off "void" is required by style guide.)

I'm persuaded by arguments from folks on #25228 (comment) though. The => form is very convenient. I think we could allow it in strong mode.

[vsmenon]

We're arguably somewhat inconsistent right now:

typedef void FOO(int x);
int y;
FOO foo = (int x) => y = x; // OK
void bar(int x) => y = x; // Warning
FOO foo2 = bar; // OK!

It's a bit odd we complain about bar, but not assignments.

@leafpetersen ?

[trinarytree]

I'm curious about why => is considered "very convenient" for setters. It's actually more verbose than using {}s by 1 character:

class A {
  var _x;
  set x(value) => _x = value;
  set x(value) {_x = value;}
}

One might try to argue that the dart formatter will transform the version with {}s into 3 lines, but ok, if that's such a problem, change the dart formatter, not the language.

There is a real downside to having => in setters. It makes it look like the return value is significant, e.g. that it may affect the value of assignment expressions like a = b = c.

[srawlins]

This is fixed as of 1.24. https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170728.md#void-changes