I get that. What I’m saying is: boxes have a place in the user model. We may hate them, but without them, we likely find ourselves “boxed” into a corner. So I don’t want them to be a library convention; I want them to be understood by, say, asType(). Otherwise we’re playing whack-a-mole.
> On May 11, 2018, at 1:58 PM, John Rose <john.r.r...@oracle.com> wrote: > > On May 11, 2018, at 10:07 AM, Brian Goetz <brian.go...@oracle.com > <mailto:brian.go...@oracle.com>> wrote: >> >>> >>> More on ValueRef: >>> >>> @ForValueTypesOnly >>> interface ValueRef<T extends ValueRef<T>> { >>> @CanBeFreebieDownCast >>> @SuppressWarnings("unchecked") >>> default T byValue() { return (T) this; } >>> } >>> >>> Ignore the annotations for a moment. >> >> ... and the magic-ness of it. >> >> IMO, I think one of the biases that has driven us into this corner is the >> distaste for boxes. I think we've tried too hard to say "there are no >> boxes". I think we should admit there are boxes, maybe ValueRef is spelled >> "Box<V>" or V.BOX (where reference types box to themselves). And then it >> has all the behavior of a heavy box, for better or worse. >> > > I suspect you don't yet realize how *little* magic there is in this > particular spelling of V.BOX. It requires no VM changes, using > only existing descriptors available today. It can hand you > nullable types as *as a source code convention* above both > the language and the VM. With a little magic (very little) it > can serve as as a translation strategy totally above the VM > for V and V.BOX. > >
