Spec allows function literals in initializer list

[lrhn]

Example code:

class C {
 final int x;
 C() : x = (){ return 42; }();
}

main() {
  print(new C().x);
}

This errs with the message:
'file:..../initcall.dart': Error: line 3 pos 13: unexpected token ')'
 C() : x = (){ return 42; }();

The grammar allows the syntax.

[DartBot]

This comment was originally written by @mhausner

---

The grammar does allow it, you are right. Two years ago we discussed the same issue because having function literals in field initializer expressions leads to ambiguous code. Consider this:

class C {
  C(a) : x = (a) => a;
  ...

Is field x initialized to a function literal and the constructor has no body, or is field x initialized to (a) and => a; is the body of the constructor?

The old ANTLR grammar used to have a tie-braker rule that made it impossible to have function literals in initializer expressions (unless nested in parenthesis). I don't see such a rule in the spec now.

Gilad, have we made the conscious decision to allow function literals in initializer expressions, or is this an oversight in the current spec?

---

Set owner to @gbracha.

[gbracha]

The grammar needs to be reviewed for such issues. This is a bug in the grammar.

[DartBot]

This comment was originally written by @mhausner

---

Issue #11508 has been merged into this issue.

---

cc @gbracha.

[peter-ahe-google]

Is this "Area-Language"?

[peter-ahe-google]

Issue #11508 has been merged into this issue.

[DartBot]

This comment was originally written by @mhausner

---

Maybe more Area-Spec it that existed.

---

Removed Area-VM label.
Added Area-Language label.
Changed the title to: "Spec allows function literals in initializer list".

[bwilkerson]

Marked this as blocking #11828.

[lrhn]

Issue #15626 has been merged into this issue.

[lrhn]

If we disallow '=>' for the body of generative constructors, I think the grammar would no longer be ambiguous.
It's still hard to parse because you need arbitrary lookahead, e.g., for:
  C : x = (y) { long thing that could be a body } ; // ';' <- the real body.
but it's probably easier to specify than recursively disallowing undelimited function expressions in a conditionalExpression.