Is V? what we need ?
john.r.rose at oracle.com
Wed May 1 23:12:24 UTC 2019
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.
More information about the valhalla-spec-experts