I'm not against changing what a type pattern is but it should be done
in concert with changing the other rules (overriding rules
especially) and the retrofitting of primitive types to value classes.
It's not about "changing other rules", its about aligning to them.
We're aligning to cast conversion here. When we have named patterns,
we will have to define overload selection for patterns; again, this
should just be the existing overload selection with "arrows reversed",
which means we want boxing for patterns to also be "boxing with arrows
reversed" (otherwise it doesn't compose.) The language we have now is
telling us how patterns should work; we should listen.
Just in case it's not clear:
- instanceof T means "is it safe to cast to T"
- non-unconditional type patterns (those that do not resolve to any
patterns) mean `instanceof T`
And this is true for primitive and reference types, primitive and
reference targets. This isn't special new rules for primitive type
patterns, it is extending instanceof to mean "is it safe to cast" and
then defining type patterns purely in terms of instanceof.
Other useful things follow too:
- for types S and T, if all values of S are instanceof T, then `T t`
is unconditional on S (no distinction between primitive and reference types)
- with the same condition, `T t` dominates `S s`
- if S is cast-convertible (modulo unchecked conversions) to T, then
`T t` is applicable to S (no distinction between primitive and reference
types)
If you read the new spec (Aggelos will post a draft soon), you'll see
that we hardly even mention primitive types in the section on type
patterns. We just define type patterns in terms of exact casts, and
same for instanceof. Pretty much all the new text is "what is an exact
cast".
