So, who is bothered by the fact that case #3 gets Box(null), and
case #6 gets Bag(null)? Anyone? (And, if not, but you are
bothered by the lack of totality on the true catch-alls, why not?)
I'm bothered if the pattern are not declared as total
That's too bad, because there was a proposal that might work (`default`
enables type checking for totality on switches) and now you want to
escalate it to something that "totally" does not work (`default` makes
_patterns_ total.)
and i believe Stephen Colebourne on amber-dev is proposing exactly the
same rules.
You should read my long explanation to Stephen over there. TL;DR: this
is not engaging with half of what pattern matching is really for, and so
is coming to the wrong answer. Totality needs to be a property of the
pattern, not the context -- otherwise, the same pattern in switch
doesn't mean the same pattern in instanceof, and each construct needs
its own totality hacks. This is just another bad variant; worse, in
fact, that the "any x" proposal.
Having total patterns is very important; if I have:
record Bag<T>(T t) implements Container<T> { }
record DoubleBox<T>(InnerBox<T> x) implements Container<T> { }
record InnerBox<T>(T x) { }
and I do
switch (container) {
case DoubleBox(InnerBox(var x)): ...
}
the outer pattern is not total on Containers (doesn't match Bag), but
the inner pattern is once we match DoubleBox. I want to match all
DoubleBoxes, and destructure their contents. If I try to wedge totality
into patterns through switch case modifiers, then (a) the totality is
all or nothing, at all levels, and (b) what do I do when I want to
refactor that switch into a chain of instanceof operations? Then
there's no way to express the pattern I want! Totality must be a
property of the pattern, and then we can define (orthogonally, please)
how the patterns interact with the enclosing construct.
I think the mistake that is dragging you down the wrong road is the
assumption that pattern matching is always about conditionality. But
destructuring is just as important as conditionality. Sometimes a
pattern is total (on a given type), and sometimes its not, but in all
cases it describes the same destructuring. What was wrong with the
"just use case var x" proposal is that it said "you can't use
destructuring when you're total, because a null might sneak along for
the ride", which was just mean.
