JEP325: Switch expressions spec

[Gavin Bierman]

Thanks Maurizio. Some replies inline.

> On 13 Apr 2018, at 12:15, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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.

Yes, you spotting me setting things up for a future release :-) But in my defence: in the current spec, we say “case constant” where constant is either a constant expression or an enum constant. We are adding to this the possibility of a “null”, so we need to find another word anyhow. That said, I think you have a point, so I’ll look again to see if I can dial it down a bit. 

> 
> * 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.

I know what you mean, but the spec today already states “...then we say that the case label *matches*.” So I actually kept that text as it is. 

> 
> * 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

I’ll take another look.

> 
> * "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).

This is a good question, although probably only one for spec-nerds. The problem is that the concept of “transfer of control” is only valid for statements - in essence you jump from one statement to the other. There is no concept in the JLS of control for *expressions*. So you can’t really say that the break statement with a value transfers control to an *expression*. This is what is so “unusual” about switch expressions, they are expressions with statements inside...

This either/or distinction makes clear, for better or for worse, the new dual nature of break statements: they either transfer control to another statement, or they end up returning a value to an enclosing expression.


> 
> * 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).

Thanks! Although, with the proposed change to forbid fall through from statement groups into clauses, I’m not sure they can stay.

> 
> * 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.

Yes! Thanks.


> * 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.

Yes! Thanks.

> 
> * 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?

Yes, although I’m not sure I quite see the “contradiction”. I’ll take another look at this text.


> * 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.

Okay, thanks.

> 
> 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
>