"Model 2" prototype status

[Kervin Pierre]

Thanks a Gavin, Brian for the very clear definition of the problem
( along with all the time spent solving it ).

Simple question... I can't help to think ( although I may be incorrect )
that a massive amount of this issue goes away ( for new programs ) with
a unified object/valueType hierarchy and availability of autoboxing
tweaks.

1. A sort that matches primitives but instructs the compiler to box them
to value types.  This would not replace the sort that matches but does
not box, e.g. 'anyObject' and 'any' respectively.  Also 'anyObject'
would match 'ref'.

2. Value type hierarchy base object appearing to the compiler has
Object.

Some popular languages seem to have success with this approach.  And at
least on the surface it seems to solve nullability and and host of other
API issues that have been discussed.

More out of curiosity than anything else, is there anything inherently
wrong/broken with the above approach?

Best regards,
Kervin

On Mon, 2015-08-03 at 11:00 -0400, Brian Goetz wrote:
> > Placing a sort on a type variable in, for example, a class declaration
> > can have consequences in the declaration body. If you declare a class
> > `Pop<any T>` you are declaring it *for all* instantiations of T,
> > including primitives. Hence in the body of declaration, you shouldn’t be
> > able to assign null to an instance of the type variable, for example. It
> > breaks the contract in the declaration. This is no different to Java 8,
> > where we check in the body that we respect the bounds contract on type
> > variables.
> 
> Don't forget nullability is just an example here of the category of 
> things that "classical" generics allow based on the assumption that type 
> variables only quantify over reference types.
> 
> A similar restriction is that you can't use an avar as the lock object 
> for a synchronized block.  Why?  Because the lock object has to be an 
> _Object_.  And if T is an any-var, it might be an int -- which means you 
> can't use it as a lock object.
> 
> Same for:
>   - Object methods that are not going to be lifted to values (it seems 
> likely that equals/hashCode/toString/getClass will find their way to 
> values, and that wait/notify will not.  (But note this has little to do 
> with anyfied generics directly -- this has to do with the properties of 
> value types when we add them to the type system.  Of course, the goal 
> here is that generics interact nicely with value types, but the two are 
> separate problems.)
>   - Assumptions that T[] <: Object[]; this is true for reference T but 
> not for value T.
> 
> Again, these restrictions are simply consequences of quantifying over a 
> heterogeneous sort of types; if there's at least one type (e.g., int) in 
> the sort "any T", then things like "synchronized (T)" or "T = null" 
> can't be allowed because we can't be confident they mean something.
> 
> This is no different from restrictions we impose now.  For example:
> 
> class Foo<T> {
>      T t;
> 
>      ... I can call t.toString() ...
> 
>      ... But I can't call t.intValue() because I have no reason to 
> believe this method exists on T ...
> }
>