Hi, I have a few points regarding this – since there was a flurry of mails last night/day, I have given references below to specific threads below:
-As Maurizio pointed out in https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001334.html , “yield” is not really a _reserved_type_identifier_ like “var” – “var” is correct only at places (at some places actually) where a type can occur- Our view point: At parsing time “var” is just taken as a type and hence from a compiler implementation point of view, “var” is less of a challenge than the proposed “yield”. If “yield” value is used instead of “break” value, then again, the compiler needs to disambiguate – the disambiguation problem just manifests in a different avatar. -Alex, in the discussion here https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001338.html has pointed out that “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” where The reference [1] is “[1] See slides 9-11 from https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html “ Our View point: However, though the problem was resolved finally for lambda, additions of new context sensitive keywords would make our parsing more complicated with additional logic in lookaheads. Although the problem was solved from a pure compiler perspective, we are far from winning the battle as an IDE where one major value add is code completion, which works on incomplete code. Due to these hacks, code completion for lambdas still has unresolved issues for us. - An additional input to this discussion is the proposal for hyphenated keywords as described in https://openjdk.java.net/jeps/8223002. “break-with” which was the earlier proposed one, was one among these hyphenated keywords. Our View point: We are fine with that as mentioned in the mailing list sometime earlier in the context of switch expressions and break-with, the hyphenated keyword. The more the number of context sensitive keywords are introduced, causing more hacks, it would be really difficult to sustain and scale the Eclipse IDE. - Based on the above, I believe “break-with” was a better candidate with less or disambiguation and it goes along with the future direction of keywords. Here the assumption is break-with is not context sensitive at any point in time. Given that “break-with” had opposition, and “yield” was more popular candidate, planning to reply with a new suggestion of hyphenated keyword “yield-value” or any other hyphenated keyword. Regards, Manoj. Eclipse Java Dev. From: Remi Forax <fo...@univ-mlv.fr> To: John Rose <john.r.r...@oracle.com> Cc: amber-spec-experts <amber-spec-experts@openjdk.java.net> Date: 05/17/2019 01:00 PM Subject: [EXTERNAL] Re: Call for bikeshed -- break replacement in expression switch Sent by: "amber-spec-experts" <amber-spec-experts-boun...@openjdk.java.net> ----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 17 Mai 2019 08:41:20 > Objet: Re: Call for bikeshed -- break replacement in expression switch > (Going back to the start of this thread.) > > On May 12, 2019, at 12:38 PM, Brian Goetz <brian.go...@oracle.com> wrote: >> >> We could surely take “break-with” and move on; it feels sufficiently “switchy”. > > If "break L" breaks out of a statement introduced with "L"… > > Then… > > "break ->" could break out of a statement introduced with "->". It's not logical for me, it's not "L", it's "L:". If it was "break :L", i would agree. Rémi
