Switch expressions spec

[Alex Buckley]

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

> 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