The storage hint model

[Maurizio Cimadamore]

> The main difference is that ".val" requires two types for one value class that are similar but not quite the same.
>
> Differences between C and C.val is really hard to understand because those types are really similar but obey to different rules
> - C and C.val have no subtyping relationship but if you see a type as a set, C accept null while C.val don't.
> - you have auto-boxing between a C and a C.val
> - overloading rules should prefer C.val to C (but maybe not)
> - the inference with C.val doe not work exactly like the inference with C
> - an array of C.val is a subtype of an array of C
> - List<C> and List<C.val> are incompatible types
> - instanceof C.val is not valid
> - c.getClass() with c a C.val is typed Class<? extends C> (not C.val).
> and this is not an exhaustive list and i'm sure some of them are wrong because even us, experts, have trouble to define the correct set of rules.

Some of these differences are covered in this JEP draft:

https://openjdk.org/jeps/8261529

In particular, search for "parameterized type conversions".

Of course the document talks about conversions between C and C.ref, but 
the same would apply, I think, to C and C.val.

I get what you are saying: adding a new type (or a new pair of types) is 
a big thing in terms of user model, especially if they come with 
complicated rules as to how they should be used, and how they propagate 
through overload resolution and inference rules.

But, the idea of having pairs of types with an autobox relationship 
between them is not exactly new (int -> Integer), so we'd also be 
playing on a tune that developers are familiar with.

In any case, I don't think we can rule out this approach w/o first 
pulling the string in full and see where it leads. It might be (as you 
say) that pairs of related types are hard to reason about in user code. 
Or it might be that we come up with the right mix of type system 
enhancements that is enough for people not to care 99% of the time.

In other words, it seems to me that we're jumping ahead a little here: 
yes, we should make sure that whatever we come up with makes sense with 
universal generics, but it doesn't seem to me that either (a) the 
universal generic draft dismisses any of your concerns or that (b) we 
are far enough down that route to draw a conclusion one way or another.

Maurizio