Open modulovalue opened 8 months ago
There appears to be an inconsistency wrt unary prefix
-
,~
andawait
operators on function expression literals between the implementation and DSP.
This is presumably a consequence of the fact that the grammar in the language specification includes <functionExpression>
as one of the alternatives of <primary>
, and the grammar in Dart.g
splits <functionExpression>
into <functionPrimary>
(which is only able to derive function literals whose body is a block: { ... }
) and <functionExpression>
(which is only able to derive function literals whose body starts with an arrow: =>
), and derives the former from <primary>
and the latter from <expression>
. Presumably, the implementation uses the same approach as the language specification.
However, the rules in the language specification are highly ambiguous. In particular, an expression of the form (...) => e
can typically be parsed in many different ways, because e
may end in terms that may be applicable to the body of the function as well as to the function as a whole. For example: () => a.b.c
may mean () => (a.b.c)
, (() => a.b).c
, or (() => a).b.c
.
I changed the approach in Dart.g when I created Dart.g (because the blatant ambiguity had to be handled, and also just because we ought to fix that issue), but it hasn't yet been accepted into the language specification.
With the approach in Dart.g, ~() => 0
is a syntax error (because <unaryExpression>
cannot derive () => 0
), and similarly for unary -
and await
. However, ~() { return 0; }
would be fine, and so would -() { return 0; }
and await () { return 0; }
, as well as parenthesized versions of the =>
variants (~(() => 0)
, etc).
So I'd prefer to say that this issue will be resolved by fixing the ambiguity in the implementation and specification based on the approach in Dart.g.
There appears to be an inconsistency wrt unary prefix
-
,~
andawait
operators on function expression literals between the implementation and DSP.Consider:
and
and
DSP rejects those operators in that position, but those operators are supported by the implementation:
Note: something similar can be observed with
!
, i.e.final a = !() => 0;
, but, AFAIK, ! is never supported as an operator on function expression literals.