I suspect there are other orderings too, such as "any nulls beat any
novels" or vice versa, which would also be deterministic and potentially
more natural to the user. But before we go there, I want to make sure
we have something where users can understand the exceptions that are
thrown without too much head-scratching.
If a user had:
case Box(Head)
case Box(Tail)
and a Box(null) arrived unexpectedly at the switch, would NPE really be
what they expect? An NPE happens when you _dereference_ a null. But no
one is deferencing anything here; it's just that Box(null) fell into
that middle space of "well, you didn't really cover it, but it's such a
silly case that I didn't want to make you cover it either, but here we
are and we have to do something." So maybe want some sort of
SillyCaseException (perhaps with a less silly name) for at least the
null residue.
On the other hand, ICCE for Box(novel) does seem reasonable because the
world really has changed in an incompatible way since the user wrote the
code, and they probably do want to be alerted to the fact that their
code is out of sync with the world.
Separately (but not really separately), I'd like to refine my claim that
`switch` is null-hostile. In reality, `switch` NPEs on null in three
cases: a null enum, String, or primitive box. And, in each of these
cases, it NPEs because (the implementation) really does dereference the
target! For a `String`, it calls `hashCode()`. For an `enum`, it calls
`ordinal()`. And for a box, it calls `xxxValue()`. It is _those_
methods that NPE, not the switch. (Yes, we could have designed it so
that the implementation did a null check before calling those things.)
The ambiguity that this analysis still does not addresses situations
such as D(E(novel, null)); this example is briefly alluded to at the
end of Brian’s initial sketch of the formalism, but unfortunately the
sketch does not address multi-parameter deconstructs in detail. So
let’s go through this example: suppose that there are explicit cases
that are optimistically total (I like the terminology Brian has
provided) on D(E(Shape, Coin)), which might look like this:
D(E(Round, Head))
D(E(Round, Tail))
D(E(Rect, Head))
D(E(Rect, Tail))
Then I think the residue would consist of
D(null)
D(novel)
D(E(null, null))
D(E(null, Head))
D(E(null, Tail))
D(E(null, novel))
D(E(Round, null))
D(E(Rect, null))
D(E(Round, novel))
D(E(Rect, novel))
D(E(novel, null))
D(E(novel, Head))
D(E(novel, Tail))
D(E(novel, novel))
The order shown above is permissible, but some pairs may be traded,
under the constraint that if two cases differ in one position and one
of them has “null” in that position, then that one must come earlier.
If we wish behavior to be deterministic, it would be Java-like to
insist that (1) the cases be listed consistent with an increasing
lexicographic partial order, where null < novel, and (2) that
sub-patterns effectively be processed from left right. Under these
rules, the cases
D(E(null, null))
D(E(null, novel))
would raise NPE, and
D(E(novel, null))
D(E(novel, novel))
would raise ICCE.
