----- Original Message ----- > From: "Maurizio Cimadamore" <[email protected]> > To: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "valhalla-spec-experts" > <[email protected]> > 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
