The storage hint model

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Friday, July 22, 2022 12:30:45 PM
> Subject: Re: The storage hint model

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

Yes, i don't disagree with your last paragraph but adding autoboxing between C and C.val has a strong starwars (prequels) vibe to me,
Anakin (value class) you were the one supposed to rebalance the force, healing the rift between objects and primitive types, not adding more auto-boxing.

I believe we are adding complexity to the spec/compiler in order to manage the relationship between C and C.val where users will be totally fine declaring both of them as separate types and doing the conversions by hand, and in a safer way, not bypassing the constructor when doing a conversion from C.val to C. 

> 
> Maurizio

Rémi