New JEP: Switch Expressions for the Java Language

[Brian Goetz]

On 12/7/2017 6:28 PM, Liam Miller-Cushon wrote:
> I don't see it mentioned in the JEP, but will the default case of an 
> expression switch be required to be last? (Previously: 
> http://mail.openjdk.java.net/pipermail/amber-spec-observers/2017-November/000134.html)

We've not fully worked through these details yet.  Here's my current 
thinking.

We don't want to bifurcate the world into legacy switch and new switch.  
Instead, we'd like to generalize switch, and then, where something makes 
sense for (say) int switch but not for the general case, specify those 
restrictions in terms of what's in the case labels.  (For example (not 
saying we will do this), take fallthrough.  If we decided we were going 
to kill fallthrough in patterns, rather than saying "no fallthrough in 
pattern switch", we'd say "no falling into patterns of XYZ kind.")

The so-called-legacy switches have an interesting property; all their 
cases, other than default, are mutually exclusive.  (If you match "foo", 
you can't match "bar".)  This means that ordering is irrelevant (modulo 
fallthrough.)  OTOH, with more interesting switches, a case can subsume 
another case, so its important that they be put in the right order 
(having "case Object" before "case String" would mean the latter is 
dead, and we treat this as an error.)  In this light, "default" means 
"case anything else", so if there's even a tiny bit of room for 
confusion, it should go last.

What we do about existing switches is still open.  For consistency[1], 
we might want to remake the world to say "default goes last."  But, this 
has a cost (needless code churn, which will be viewed as ceremony), and 
its not clear the consistency benefit is warranted.  So we might say 
something like "if any case label in the switch has a defined dominance 
ordering with any other case label, default must be the last case."  
That way old code continues to work, but once you migrate to nontrivial 
patterns (which involves source changes anyway), you need to put things 
right.  This seems a good compromise.

For expression switch, we can be a little stricter, since there's no 
existing code.  On the other hand, its good to have the same set of 
rules for expression and statement switch (all things being equal). So 
this could go either way.

[1] Language-evolution arguments that start with "for consistency, ..." 
are usually weak.

> > in the case of an enum switch that covers all known cases, a default 
> clause can be inserted by the compiler that indicates that the enum 
> definition has changed between compile time and runtime
>
> This sounds great, but note that it makes adding values to an enum a 
> potentially source-incompatible change. Pattern switches that handle 
> all values of an enum will need to be updated to handle the new value, 
> or to have an explicit default.

Yes, but that doesn't bother me so much.  Adding a member to an enum 
that is exposed across compilation unit boundaries should be an unusual 
case.  If someone has explicitly coded defensively to deal with this, 
great.  If they haven't, having their switch code break when someone 
else changes an assumption out from under them is a good thing.

Users (rightly) find it irritating that, when they define an enum:

     enum TrafficLight { RED, YELLOW, GREEN }

that they constantly have to deal with "might be some other color." Not 
all enums have this characteristic, but many do, and I think its 
reasonable to let users err on the side of this assumption.  They can 
always code an explicit default if they want.