value type hygiene

Brian Goetz brian.goetz at
Sat May 12 14:34:27 UTC 2018

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.rose at> wrote:
> On May 11, 2018, at 10:07 AM, Brian Goetz <brian.goetz at <mailto:brian.goetz at>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the valhalla-spec-experts mailing list