Call for bikeshed -- break replacement in expression switch
manoj.palat at in.ibm.com
Fri May 17 14:55:14 UTC 2019
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
, “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
has pointed out that “The parsing of a `(` token has triggered potentially
unbounded lookahead for some time , and everything worked out, so I
don't see why the language should disallow any of John's examples” where
The reference  is “ See slides 9-11 from
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
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.
Eclipse Java Dev.
From: Remi Forax <forax at univ-mlv.fr>
To: John Rose <john.r.rose at oracle.com>
Cc: amber-spec-experts <amber-spec-experts at openjdk.java.net>
Date: 05/17/2019 01:00 PM
Subject: [EXTERNAL] Re: Call for bikeshed -- break replacement in
Sent by: "amber-spec-experts"
<amber-spec-experts-bounces at openjdk.java.net>
----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at 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.goetz at oracle.com> wrote:
>> We could surely take “break-with” and move on; it feels sufficiently
> If "break L" breaks out of a statement introduced with "L"…
> "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.
More information about the amber-spec-observers