Apologies for my slow responses.
> On 6 Mar 2019, at 21:53, Alex Buckley <[email protected]> wrote: > > Hi Gavin, > > On 3/6/2019 1:51 AM, Manoj Palat wrote: >> *1: In section, *14.15 The breakStatement >> >> A breakstatement transfers control out of an enclosing statement_, or >> causes an enclosing __switch__expression to produce a specified value_. >> >> >> /BreakStatement:/ >> break[~~ /Identifier/~~]; >> _break___/_Expression_/___;_ >> _break____;_ >> >> the identifier is dropped – That looks like a typographical issue (since >> it was mentioned that there was not functional difference) – Identifier >> is mentioned in the statements following the above para as well. Similar >> issue is displayed in "continue" section also. > > The dropping of the `break [Identifier]` alternative looks like an editing > error when the spec document was being reformatted; compare: > > old format: > http://cr.openjdk.java.net/~gbierman/switch-expressions-2019-01.html#jep325-14.15 > > new format: > http://cr.openjdk.java.net/~gbierman/switch-expressions.html#jep325-14.15 Apologies Manoj - looks like our migration to a new markdown style has a couple of glitches. Yes, the grammar is intended to match the text below, i.e. _BreakStatement_: `break` _Identifier_`;` `break` _Expression_`;` `break` `;` (and similarly for `continue`). > >> 2. A related query, though a bit late, but better late than never:) - : >> In the Eclipse Compiler implementation we assume expression encompasses >> identifier (in the syntax context), and then deduce whether this is a >> label or an expression later in the resolution context. From the grammar >> above, it does not look like we can distinguish whether an identifier is >> a label or an expression in the first place? An explicit statement in >> the spec about how to distinguish would be helpful. > > This will become moot if the change anticipated by Brian happens (change > “break value” to “break-with value”). Yes, the proposal is that we will move to `break-with` and so side-step this issue :-) > Until then, Manoj is asking a great question. Per 6.2, a label is not a name, > but per 14.7, a label does have scope, and: > > "There is no restriction against using the same identifier as a label and as > the name of a package, class, interface, method, field, parameter, or local > variable. Use of an identifier to label a statement does not obscure (§6.4.2) > a package, class, interface, method, field, parameter, or local variable with > the same name. Use of an identifier as a class, interface, method, field, > local variable or as the parameter of an exception handler (§14.20) does not > obscure a statement label with the same name." > > I seem to recall a discussion recognizing and accepting the source > incompatibility of recasting `break X;` from "Jump to label X" to "Evaluate X > and yield the result". Such acceptance would suggest an edit to the last > sentence quoted above. Quite. The following code is erroneous according to the spec: int l = 0; int i = 42; l : System.out.println(switch (i) { default -> { break l; } }); javac correctly reports: error: ambiguous reference to 'l' l : System.out.println(switch (i) { default -> { break l; } }); ^ ('l' is both a label and an expression) So the text Alex quotes would need tweaking, should we keep the value break statement. > >> 3. In section, 5.6 *– “*_A _*/_unary numeric promotion_/*_applies >> numeric promotion to an operand expression and a notional non-constant >> expression of type _*int*_.”_ >> It will be nice to explain in the spec a little more as to what is meant >> by “a notional non-constant expression” ? > > I believe more polishing is already on the way for the recast definition of > numeric promotion? Let me look at that text. Thanks for the pointer. Gavin
