Is V? what we need ?

[John Rose]

I buy your argument, Brian, for shedding boxes from
the center of the user model for V and V?.

Given that V and V? have different contracts (per my
previous note), so that they can have different physical
representations in the JVM, it turns out that this statement:

   V is a subtype of V?  (for any inline type)

is true in pretty much the same way as this statement:

   int is a subtype of long

Does that mean their formats are the same?  No.  (In fact
their descriptors are of wholly different *kinds*.)  Is the
value set of one a superset of the other?  Why yes.  Can
overloading selection (first phase!) choose either but
prefer the narrower?  Oh, yes.  (No boxes in that phase.)
Is it a different kind of super-type relation that inheritance?
Yes, it's a corner case in the JLS.

(Are their respective arrays related?  Hmm, that's interesting.
We've been round and round on this one.  It looks like V?
and V are closer in that respect than int and long.)


> On May 1, 2019, at 12:34 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> However, I think my more general point remains - the fact that the VM has the flexibility to treat V and V? as, fundamentally, the same thing shouldn't necessarily drive the conclusion that, _at the language level_ there should be a subtyping relationship between V and V?.
>> 
>> From a pedagogical perspective, whether we like it or not, users are immediately going to think in terms of box/unbox, so I think it'd be surprising if the new inline classes and their projections had rules radically different from those which apply to the int/Integer case.
> 
> I agree that users are going to first reach for the box/unbox intuition.  So let's talk about what's going to happen there.
> 
> Let's assume that `V` translates to `QV` and `V?` translates to `LV`; let's compare the language we get under a subtyping relationship or a boxing conversion.  (Either way, we get V? <: Object.)
> 
> The box intuition says you can lock on a box (though we discourage it.)  But locking on a V? will result in an exception.  (Same for wait/notify.)
> The box intuition says that == on a box is an identity comparison. But a V? has no identity (it did in Q-world, not in L-world.)
> The box intuition says you can create a weak reference of a box. But you cannot for a value.
> 
> So there are multiple ways in which the box intuition _already_ leads users down the wrong road, regardless of whether it is subtyping or not.
> 
> One big difference between whether we convert V to V? via subsumption or via a boxing conversion is how overload selection is done.  But, if we have methods m(Object) and m(V?), and it is invoked with a v, in the subtyping case, we'll select m(Object), and in the conversion case, we'll select m(V?).  But it's not clear that this is what we want -- I would think to most people, V? feels "more specific" than Object.  The rules regarding "try first without boxing" exist solely for compatibility; they are not necessarily the rules we would have wanted had we started with autoboxing in 1.0.
> 
> If we define the relationship between V and V? as boxing, then equality comparisons between V and V? similarly have to go through boxing.  This is doable, but under subtyping, it is simpler -- do they refer to the same value.
> 
> Overall, I'm not really seeing much of value (that joke never gets old) for the "it's a boxing conversion" route; it's more complexity in the language, but the boxing intuition is not really serving the user very well in the first place.
> 
>