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