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

Reply via email to