[switch] Status of implementation of switch expression
brian.goetz at oracle.com
Tue Feb 27 22:22:37 UTC 2018
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
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....
More information about the amber-dev