JEP325: Switch expressions spec

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Apr 13 11:15:01 UTC 2018


Looks neat. Some comments:

* I note that you introduced patterns to describe the new syntactic 
options; while that's a completely fine choice, I wonder if it could 
lead to confusion - I always thought of JEP 325 as a set of standalone 
switch improvements, which don't need the P-word to be justified. Of 
course, I'm not opposed to what you have done, just noting (aloud) the 
mismatch with my expectations.

* in 14.11 I find these sentences:

"then we say that the null pattern matches", "then we say that the 
pattern matches"

A bit odd to read , as the transitive verb 'matches' is missing its object.

* also I note some replication:

"If all these statements complete normally, or if there are no 
statements after the pattern label containing the matching pattern, then 
the entire switch statement completes normally."
"If all these statements complete normally, or if there are no 
statements after the pattern label containing the matching pattern, then 
the entire switch statement completes normally."
"If all these statements complete normally, or if there are no 
statements after the default pattern label, then the entire switch 
statement completes normally."

The first two are identical, the last only slightly different, perhaps 
something can be done to consolidate

* "A break statement either transfers control out of an enclosing 
statement or returns a value to an immediately enclosing switch expression."

Is it an either/or? My mental model is that break always transfer 
controls out - it can do so with a value, or w/o a value (as in a 
classic break).

* I like the fact that you define the semantics of the expression switch 
clauses in terms of desugaring to statements blocks - this is consistent 
with what we do in other areas (enhanced for loop, try with resources).

* I suggest putting the paragraph in 15.29 starting with:

"Given a switch expression, all of the following must be true"

Ahead of the desugaring paragraph, which seems more 
execution/semantics-related, while this one is still about well-formedness.

* On totality - this line:

default                     -> 10; // Legal

deserves some more explanation - e.g. one might think it's unreachable, 
but it's not because new constants could pop up at runtime; maybe add a 
clarification.

* On non-returning, this sentence is obscure:

"Thus a switch expression block that can not complete normally, can only 
do so by occurrences of a break statement with an Expression. This 
ensures that a switch expression must either result in a value, or 
complete abruptly."

because it contradicts what is said just a line above:

"an occurrence of a break statement with an Expression in a switch 
expression means that the switch expression will complete normally with 
the the value of the Expression"

The way I read this is:

1) the only way for the block after a 'case' in a switch pattern to 
complete abnormally is via a break expression
2) even if the _block_ completes abnormally, the containing switch 
expression will complete normally, with the value of Expression

Is that what you meant?

* At the end of the switch expression section there are sub-optimal 
sentences like the one that appear for switch statements (e.g. "pattern 
matches") - see above.

Cheers

Maurizio

On 12/04/18 22:27, Gavin Bierman wrote:
> I have uploaded a draft spec for JEP 325: Switch expressions at http://cr.openjdk.java.net/~gbierman/switch-expressions.html
>
> Note there are still three things missing:
>
> * There is no text about typing a switch expression, as this is still being discussed on this list.
> * There is no name given for the exception raised at runtime when a switch expression fails to find a matching pattern label, as this is still being discussed on this list.
> * The spec currently permits fall through from a "case pattern:” statement group into a "case pattern ->" clause. We are still working through the consequences of removing this possibility.
>
> Comments welcomed!
> Gavin



More information about the amber-spec-observers mailing list