RFR: JDK-8223305: Compiler support for Switch Expressions

[Alex Buckley]

On 5/31/2019 5:26 AM, Florian Weimer wrote:
> * Jan Lahoda:
>
>> Hi,
>>
>> I'd like to ask for a review of changes to update javac to follow the
>> current spec for switch expressions, in particular the break -> yield
>> change:
>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html
>
> I think the purpose of these rules is to avoid certain forms of
> non-local control flow (and avoid specifying whether the loop control
> expression(s) are part of the loop or not):

I believe that Jan was asking for a review of the javac changes 
(appropriate for compiler-dev) rather than the spec changes (belongs on 
amber-spec-{experts,observers,comments}).

> | It is a compile-time error if the break target of a break statement
> | contains any method, constructor, initializer, lambda expression, or
> | switch expression that encloses the break statement.
>
> | It is a compile-time error if the continue target contains any method,
> | constructor, initializer, lambda expression, or switch expression that
> | contains the continue statement.
>
> | It is a compile-time error if the return target contains any
> | initializer, or switch expression that encloses the return statement.
>
> Are these rules really technically correct?  Maybe it's more obvious to
> define the target in such a way that it must be located within the same
> method, constructor, or initializer.  I think then it's possible to
> require that the break/continue/return target must not contain any
> expression that also contains the break/continue/return statement.  (And
> also define that do/for/switch/while statements contain both the body
> and the expression(s).)

The rules you quoted are a smooth extension (to include switch 
expressions) of the longstanding rules that prevent non-local jumps by 
`break` and `continue`, and bad jumps by `return`. You didn't quote the 
corresponding rule for `yield` whose form aligns with the rules above. 
Minimizing churn and maximizing alignment are very good things in a 
spec. The policy being implemented by the rules was given in 
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-April/001232.html 
(for `break-with` and `break-e`, read `yield`).

> For a specification point of view, I think it might be more
> straightforward to specify statement expressions first and then use them
> to define switch expressions.

Not sure what you mean. Statement expressions exist so that an 
expression can appear either as a subexpression or as a top-level 
statement (followed by `;`, i.e., an expression statement). Defining a 
switch expression as a statement expression would imply that a top-level 
switch statement is followed by `;`, which is wrong.

If you have further spec feedback, please send concrete proposals 
(rather than outlines of what might be possible) to amber-spec-comments.

Alex