[switch] Status of implementation of switch expression

[Brian Goetz]

Allowing default anywhere but last when you have any non-constant 
patterns certainly is extra-logical (but not new); the logical rule is 
that case arms cannot be subsumed by earlier case arms, lest they be 
dead code (just as you can't catch Exception before IOException.)  Of 
course, we have legacy constraints to deal with here, so my very strong 
preference is to not treat default specially with respect to ordering, 
except to the extent that we must accept legacy switch constructs that 
would have been valid in Java 10 (i.e., specific acceptable types, only 
constant case labels).  Whether we draw this circle exactly or 
approximately is a minor detail which should probably be resolved in 
favor of simplicity of specification.

Given that, the rule we must adhere to is that case null must precede 
other null-matching cases (including default, but also including "var x" 
and type test patterns, but likely not destructuring patterns.)

The main argument argument for considering a special "null first" rule 
is because of the pernicious legacy behavior of switch, where we NPE 
early if the target is null.  **Users should be able to be able to tell, 
at a glance, whether this is a null-friendly or null-hostile switch.**  
Having to grovel through the entire switch to determine if it is 
null-friendly makes this considerably harder, and will lead to errors.  
(Trying to "fix" the pernicious null behavior of switch is already on 
shaky ground, as the effect of removing a "case null" is not to lump 
null in with default, but to turn it into an implicit throw.  Users who 
don't already fully understand the behavior of nulls in switch may well 
be surprised. The main reason we're supporting case null *at all* is 
that it is necessary for pattern matching; we want to be able to 
refactor case P(Q) into nested switches, and Q might be "null".)

The main arguments against are (a) its yet more new special behavior and 
(b) the user might well want to be able to lump "case null" in with 
"default" via fall-through; in switches where the default clause handles 
"unexpected values", null might well be considered one of those.

The latter could be mitigated without undermining the examination 
problem by requiring that case null always either be first or fall 
through into default.  That's an even more complicated restriction, but 
it might be the one that best meets the anticipated use cases while 
minimizing readability problems.

> In any case, null doesn't logically need further constraints.

If we want to treat null like any other constant pattern, then it cannot 
succeed a type-test label for any reference type, for the same 
domination-avoidance reasons.


In any case, we've strayed pretty far from the charter of this list 
(discussing the implementation), and are in danger of hijacking the 
"please try out the implementation" thread to the point where people 
forget our request....