New candidate JEP: 361: Switch Expressions (Standard)

[Brian Goetz]

The asymmetry with respect to totality between switch expressions and 
statements is indeed unfortunate, and one we approached from a number of 
angles, but we are boxed in on one side by compatibility, and on the 
other by semantics.  Expressions _must_ be total, so we have to enforce 
totality for switch expressions (a non-total expression is 
nonsensical.)  On the other hand, we already have switch statements, and 
they are currently not total, and trying to make them total would break 
existing code.  So we don't have a lot of latitude in our defaults.

> JEP 361 [0] only says "Obviously |switch|statements are not required 
> to be exhaustive".
> Was this discussed previously? I feel like I am missing something. 

It flows from the existing definition of switch statements, which are 
not required to be exhaustive, and so the world is full of 
non-exhaustive switch statements that handle some portion of the state 
space (perhaps either picking off the "easy" states, or pruning off the 
impossible ones and throwing an exception), and then continue on.  We 
can't break this code, so it's here to stay.

It is possible that in the future, we'll expose a way to say "total 
statement switch", which would engage the compiler's aid in proving 
exhaustiveness.  We couldn't just spell that `switch`, for reasons 
above, though.

(That this is just one more reason why "expressions are better than 
statements", and we should prefer to program with expressions when we 
can, is not very comforting.)

Your proposal:

> Probably shortsighted proposal:
> Make arrow-switch statements exhaustive (for sealed types and enums at 
> least). 

was not previously considered, but there's a good reason to not like it, 
which is: it undermines orthogonality.  The improvements to switch here 
were several orthogonal (or mostly orthogonal) changes:
  - expression vs statement
  - single-consequence vs multi-consequence case labels
  - multiple case labels on one line

That users are free to mix and match these is a benefit; composing a 
complex feature out of orthogonal simpler features make it easier to 
reason about, and hidden couplings between them would show up as sharp 
edges.  (For example, if arrow-switch statements were exhaustive but 
colon-switch statements were not, this means that the obvious 
refactoring from one to the other has subtly different semantics.)

Yes, we do have a hidden coupling with respect to exhaustiveness; we 
don't like it, but we don't see a cure that isn't far worse than the 
disease.  (Let's not rehash the supposed cure of "make a new syntactic 
form, and leave switch to rot"; this far-worse cure has already been 
discussed to death.)

So, it seems likely the best we can do is provide a way to opt into 
exhaustiveness analysis for statement switches.  This might be a 
modified keyword (e.g., `total-switch`), or some adornment of the 
default clause (`default: unreachable`), or something else.  But the 
urgency to do this NOW is limited, at least until we have more sources 
of exhaustiveness (sealed types) that are relevant to switch (pattern 
support in switch.)

Cheers,
-Brian




> Subject: Re: New candidate JEP: 361: Switch Expressions (Standard)
> Date: Mon, 28 Oct 2019 13:23:33 +0100
> From: Thomas Zimmermann <zimmermann.tho at gmail.com>
> Reply-To: Amber Expert Group Observers 
> <amber-spec-observers at openjdk.java.net>
> To: amber-spec-observers at openjdk.java.net
>
> Hello dear OpenJDK developers!
>
> I have some feedback regarding switch expressions, more precisely the 
> new non-exhaustive arrow-switch statements.
> The original code was in Kotlin, but I recreated the structure in Java 
> and the problem remains the same.
>
> Context:
> An Android app showing the current location on a map. The UI is 
> listening to a stream of update events that cover
> all corner cases of the dynamic environment that is Android:
>
> enum LocationUpdate {
>     SUCCESS, // new location, yay
>     UNKNOWN, // no location fix for whatever reason
>     PERMISSION_DENIED // user revoked permission while wewere 
> listening to GPS :(
> }
>
> (`LocationUpdate` should really be a sealed type, but let's stay with 
> one preview feature for now)
>
> The UI will react to each update as follows:
>
> void onLocationUpdate(LocationUpdate update) {
>     switch (update) {
>         case SUCCESS -> updateLocationMarker();
>         case UNKNOWN -> removeLocationMarker();
>         // woops, forgot to handle permission denied case
>     }
>     doSomethingElse();
> }
>
> I hope you can see my problem: I expected the compiler to help me even 
> when the switch does not produce a value.
> The most obvious work around is pretty terrible (useless variable, 
> yielding arbitrary values):
>
> void onLocationUpdate(LocationUpdate update) {
>     var ignored = switch (update) {
>         case SUCCESS-> {
>             updateLocationMarker();
>             yieldtrue;
>         }
>         case UNKNOWN-> {
>             removeLocationMarker();
>             yieldtrue;
>         }
>         // compiler error, good
>     };
>     doSomethingElse();
> }
>
> Probably shortsighted proposal:
> Make arrow-switch statements exhaustive (for sealed types and enums at 
> least).
> Getting back the non-exhaustiveness if desired seems simple in this case:
>
> switch (update) {
>     case SUCCESS -> updateLocationMarker();
>     case UNKNOWN -> removeLocationMarker();
>     // don't care about the other cases
>     default -> {}
> }
>
> ... whereas getting exhaustiveness from the non-exhaustive switch is 
> hard (see work around above).
>
>
> JEP 361 [0] only says "Obviously |switch|statements are not required 
> to be exhaustive".
> Was this discussed previously? I feel like I am missing something.
>
> As a sidenote, Kotlin is also missing this feature [1], maybe Java can 
> learn from this (IMO) mistake?
>
> [0] https://openjdk.java.net/jeps/361
> [1] https://youtrack.jetbrains.com/issue/KT-12380
>
> Best regards,
> Thomas Zimmermann
>
> P.S.: I'm very excited about the new upcoming features, stellar work 
> everyone!