Switch expressions spec

[Gavin Bierman]

Apologies for my slow responses.


> On 6 Mar 2019, at 21:53, Alex Buckley <alex.buckley at oracle.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190328/39a2ffd3/attachment.html>