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 <[email protected]> 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. > >
