Inference is also something we will need for pattern assignment
Box<>(var s) = box;
Yes, it would work the same in all pattern contexts -- instanceof as
well. Every pattern context has a match target whose static type is known.
- *Array patterns. * The semantics of array patterns are a pretty
simple extension to that of record patterns; the rules for
exhaustiveness, applicability, nesting, etc, are a relatively
light transformation of the corresponding rules for record
patterns. The only new wrinkle is the ability to say "exactly N
elements" or "N or more elements".
I wonder if we should not at least work a little on patterns on
collections, just to be sure that the syntax and semantics of the
patterns on collections and patterns on arrays are not too dissimilar.
This is a big new area; collection patterns would have to be co-designed
with collection literals, and both almost surely depend on some sort of
type class mechanism if we want to avoid the feature being lame. I
don't think its realistic to wait this long, nor am I aiming at doing
anything that looks like a generic array query mechanism. Arrays have a
first element, a second element, etc; the nesting semantics are very
straightforward, and the only real question that needs additional
support seems to be "match exactly N" or "match first N".
- *Primitive patterns. *This is driven by another existing
asymmetry; we can use conversions (boxing, widening) when
constructing records, but not when deconstructing them. There is
a straightforward (and in hindsight, obvious) interpretation for
primitive patterns that is derived entirely from existing cast
conversion rules.
When calling a method / constructing an object, you can have several
overloads so you need conversions, those conversions are known at
compile time.
(Note that Java has overloads mostly because there is a rift between
primitives and objects, if there was a common supertype, i'm not sure
overloads will have carried their own weights.)
When doing pattern matching, there is no overloads otherwise you will
have to decide which conversions to do at runtime.
There are no overloads YET, because the only deconstruction patterns are
in records, and records have only one state description. But that is a
short-lived state of affairs. When we do declared deconstruction
patterns, we will need overload selection, and it will surely need to
dualize the existing three-phase overload selection for constructors
(e.g., loose, string, and varargs invocation contexts.)
