On 5/16/2019 2:05 PM, Maurizio Cimadamore wrote:
There are other contexts in which we limit what can be done w/r/t/
parenthesized expressions (since these are ambiguous with cast to
generic types). So this looks like another case where the grammar has to
say - sorry no parens here.
If you're proposing to disallow a cast expression or a parenthesized
expression after a `yield` token, then I think that's not right. The
parsing of a `(` token has triggered potentially unbounded lookahead for
some time [1][2], and everything worked out, so I don't see why the
language should disallow any of John's examples:
yield (String)("answer is "+x);
yield ("answer is "+x).trim();
yield new String[]{ "answer is "+x }[0];
yield Arrays.asList("answer is "+x).get(0);
yield false ? 0 : ("answer is "+x).trim();
Alex
[1] See slides 9-11 from
https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html
[2] JLS 15.27 on the choice of `(...)` for lambda parameters :
The syntax has some parsing challenges. The Java programming language
has always required arbitrary lookahead to distinguish between types and
expressions after a '(' token: what follows may be a cast or a
parenthesized expression. This was made worse when generics reused the
binary operators '<' and '>' in types. Lambda expressions introduce a
new possibility: the tokens following '(' may describe a type, an
expression, or a lambda parameter list. Some tokens immediately indicate
a parameter list (annotations, final); in other cases there are certain
patterns that must be interpreted as parameter lists (two names in a
row, a ',' not nested inside of '<' and '>'); and sometimes, the
decision cannot be made until a '->' is encountered after a ')'. The
simplest way to think of how this might be efficiently parsed is with a
state machine: each state represents a subset of possible
interpretations (type, expression, or parameters), and when the machine
transitions to a state in which the set is a singleton, the parser knows
which case it is. This does not map very elegantly to a fixed-lookahead
grammar, however.
