Switch expressions spec
alex.buckley at oracle.com
Wed Mar 6 20:53:33 UTC 2019
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_.
> break[~~ /Identifier/~~];
> 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:
> 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?
More information about the amber-spec-observers