Right now, we've spent almost all our time on patterns whose targets are
reference types (type patterns, record patterns, array patterns,
deconstruction patterns). It's getting to be time to nail down (a) the
semantics of primitive type patterns, and (b) the
conversions-and-contexts (JLS 5) rules. And, because we're on the cusp
of the transition to Valhalla, we must be mindful of both both the
current set of primitive conversions, and the more general object model
as it will apply to primitive classes.
If we focus on type patterns alone, let's bear in mind that primitive
type patterns are not nearly as powerful as other type patterns, because
(under the current rules) primitives are "islands" in the type system --
no supertypes, no subtypes. In other words, they are *always total* on
the types they would be strictly applicable to, which means any
conditionality would come from conversions like boxing, unboxing, and
widening. But I'm not sure pattern matching has quite as much to offer
these more ad-hoc conversions.
We have special rules for integer literals; the literal `0` has a
standalone type of `int`, but in most contexts, can be narrowed to
`byte`, `short`, or `char` if it fits into the range. When we were
considering constant patterns, we considered whether those rules were
helpful for applying in reverse to constant patterns, and concluded that
it added a lot of complexity for little benefit. Now that we've decided
against constant patterns for the time being, it may be moot anyway, but
let me draw the example as I think it might be helpful.
Consider the following switch:
int anInt = 300;
switch (anInt) {
case byte b: A
case short s: B
case int i: C
}
What do we expect to happen? One interpretation is that `byte b` is a
pattern that is applicable to all integral types, and only matches the
range of byte values. (In this interpretation, the second case would
match.) The other is that this is a type error; the patterns `byte b`
and `short s` are not applicable to `int`, so the compiler complains.
(In fact, in this interpretation, these patterns are always total, and
their main use is in nested patterns.)
If your initial reaction is that the first interpretation seems pretty
good, beware that the sirens are probably singing to you. Yes, having
the ability to say "does this int fit in a byte" is a reasonable test to
want to be able to express. But cramming this into the semantics of the
type pattern `byte b` is an exercise in complexity, since now we have to
have special rules for each (from, to) pair of primitives we want to
support.
Another flavor of this problem is:
Object o = new Short(3);
switch (o) {
case byte b: A
case short s: B
}
3 can be crammed into a `byte`, and therefore could theoretically match
the first case, but is this really the kind of complexity we want to
layer atop the definition of primitive type patterns?
I think there's a better answer: lean on explicit patterns for
conversions. The conversions from byte <--> int form an embedding
projection pair, which means that they are suited for a total factory +
partial pattern pair:
class int {
static int fromByte(byte b) { return b; }
pattern(byte b) fromByte() { ... succeed if target in range ... }
}
Then we can replace the first switch with:
switch (anInt) {
case fromByte(var b): A // static or instance patterns on `int`
case fromShort(var s): B
}
which is (a) explicit and (b) uses straight library code rather than
complex language magic, and (c) scales to non-built-in primitive
classes. (Readers may first think that the name `fromXxx` is backwards,
rather than `toXxx`, but what we're asking is: "could this int have come
from a byte-to-int conversion".)
So, strawman:
A primitive type pattern `P p` is applicable _only_ to type `P`
(and therefore is always
total). Accordingly, their primary utility is as a nested pattern.
Now, let's ask the same questions about boxing and unboxing. (Boxing is
always total; unboxing might NPE.)
Here, I think introducing boxing/unboxing conversions into pattern
matching per se is even less useful. If a pattern binds an int, but we
wanted an Integer (or vice versa), then we are free (by virtual of
boxing/unboxing in assignment and related contexts) to just use the
binding. For example:
void m(Integer i) { ... }
...
plus some pattern Foo(int x)
...
switch (x) {
case Foo(int x): m(x);
}
We don't care that we got an int out; when we need an Integer, the right
thing happens. In the other direction, we have to worry about NPEs, but
we can fix that with pattern tools we have:
switch (x) {
case Bar(Integer x & true(x != null)): ... safe to unbox x ...
So I think our strawman holds up: primitive type patterns are total on
their type, with no added boxing/narrowing/widening weirdness. We can
characterize this as a new context in Ch5 ("conditional pattern match
context"), that permits only identity and reference widening
conversions. And when we get to Valhalla, the same is true for type
patterns on primitive classes.
** BONUS ROUND **
Now, let's talk about pattern assignment statements, such as:
Point(var x, var y) = aPoint
The working theory is that the pattern on the LHS must be total on the
type of the expression on the RHS, with some remainder allowed, and will
throw on any remainder (e.g., can throw NPE on null.) If we want to
align this with the semantics of local variable declaration +
initializer, we probably *do* want the full set of assignment-context
conversions, which I think is fine in this context (so, a second new
context: unconditional pattern assignment, which allows all the same
conversions as are allowed in assignment context.)
If the set of conversions is the same, then we are well on our way to
being able to interpret
T t = e
as *either* a local variable declaration, *or* a pattern match, without
the user being able to tell the difference:
- The scoping is the same (since the pattern either completes normally
or throws);
- The mutability is the same (we fixed this one just in time);
- The set of conversions, applicable types, and potential exceptions
are the same (exercise left to the reader.)
Which means (drum roll) local variable assignment is revealed to have
been a degenerate case of pattern match all along. (And the crowd goes
wild.)
