New candidate JEP: 361: Switch Expressions (Standard)

[Thomas Zimmermann]

I am satisfied with the reasoning and comforted in knowing that the 
issue was given due consideration. :)

My initial expectation probably came from watching your talks on the 
subject, but those mostly show examples of the expression form. Maybe it 
makes sense to call out this difference?

 > But the urgency to do this NOW is limited, at least until we have 
more sources of exhaustiveness (sealed types) [...]
Agreed.

Thank you for taking the time to explain this so clearly!

Best regards,
Thomas Zimmermann

On 10/29/19 11:09 PM, brian.goetz at oracle.com (Brian Goetz) wrote:
> 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