Primitive type pattern (as actually specified) is considered harmful

[Brian Goetz]

> - you define "safe" as the revert operation on something which can be 
> lossy (my brain can not compute that),

Sorry about your brain, but I think this is straightforward.  Given sets 
A and B, with a pair of functions

     f: A -> B
     g: B -> A

we can discuss properties of the composite functions `f . g` and `g . 
f`, and there are useful algebraic structures we can appeal to 
(isomorphisms, embedding-projection pairs, etc) that can characterize 
their behavior.  For example, A and B are isomorphic if `f . g == id_B` 
and `g . f == id_A`.

Type pairs like A=int and B=long form _embedding projection pairs_, 
where `g . f` is an identity function on A, and `f . g` is a 
well-behaved _approximation_ of the identity function on B (there's a 
more rigorous definition, but let's just call it "potentially lossy in a 
stable way", so that repeated application of f and g converges to an 
identity after the first loss.)  With the exception of the "weird" 
widening conversions that we borrowed too liberally from C, which are 
called "widening" but aren't, conversions pairs that are described as 
widening/narrowing pairs in JLS 5 have this property: int/long, 
int/double, float/double, String/Object, etc.

But it is really simple: c instanceof P iff the value of c is exactly 
representable in type P.

It might be tempting to say "if I can cast and cast back and get the 
same answer", but unfortunately that doesn't work, because there are 
lossy conversions whose inverse is also lossy in an exactly compensating 
way.  _This_ would be confusing.

> - it does not work well with Valhalla, especially with the phase 3 
> (i.e. let's pretend that a primitive type is a value type) *

As I said, I think this is a distraction, but if you disagree, you are 
going to need to provide a much more exhaustive description of how you 
think Valhalla will work and why this is a conflict, than just appealing 
to claims like "won't work with Valhalla."   Or, alternately, if you 
want to focus entirely on that, then that's fine, start a new thread 
(but I would expect that mail to have more "how would X work" questions 
rather than assertions about how it would work.)

> - your interpretation is surprising when i've tried to explain it to 
> others people (even to people coming to JUGs).

I believe that, but as an educator, you should well know that often 
"surprise" is not an indication of "wrong theory" but "wrong user mental 
model", which implies that what is needed is more education. If we 
consistently designed the language for least-surprise, we would very 
quickly find ourselves in a pit where we cannot add anything, both 
because something always surprises a 1995-era programmer, and because we 
would have added layers and layers of ad-hoc "what we think the user 
expects" features that we would eventually collapse under our own 
weight.  (The "implicit conversion from float to int" is an example of 
this kind of mistake, and look where that got us.)

But I still don't see anything concrete enough here to engage with. So 
again, please: start again.