Hi Gavin, On 3/6/2019 1:51 AM, Manoj Palat wrote:
*1: In section, *14.15 The breakStatementA 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
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”). 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.
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?
Alex
