Primitives in instanceof and patterns

[Brian Goetz]

>> 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".