Is V? what we need ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 2 Mai 2019 00:55:19
> Objet: Re: Is V? what we need ?

> On May 1, 2019, at 7:50 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>>> I fully agree, it's like getting ride of Integer, it's a fantasy, but not having
>>> a lot of API taking a N? as parameter type make that fantasy actually possible
>>> for the libraries you care.
>> 
>> We can’t get rid of Integer, but maybe we can make it 10x less important.  That
>> would be winning.
> 
> I agree with this.  It is an argument to "cripple" V? (aka V*)
> as Remi is suggesting.
> 
> A counter argument is that this makes code gratuitously
> hard to use; auto-unboxing of Integer is a decision to
> partially un-cripple Integer.
> 
> Fully crippled case:  The type V? has no operations except a
> null constant (V?.default), an explicit conversion from V ((V?)x),
> and an explicit conversion back ((V)x).
> 
> Fully functional case:  The type V? is a super of V, interpreted
> as V with null adjoined (if not already present), *and* all operations
> of V are lifted to V? with a NPE thrown for null.
> 
> My guess is we will end up somewhere between; there
> are many points in between, including today's policy about
> Integer.
> 
> I agree it doesn't help much to talk about "boxes" as a generic
> design tactic.  There are too many design degrees of freedom.
> Maybe there are "coffers" in our future, but the real question
> is what operations are available on V? (aka V*).
> 
> I agree with you, Brian, that the best user model outcome
> will make boxes disappear as separate APIs.  This means
> that either V? (aka V*) has a trivial API, or else its API
> differs trivially from that of V, so that the "?" denotes
> more of a mode of use, than a full-blown API.  I would
> prefer the latter.

So let's call it V*. I want also make clear that there is no proposal to not have a V*, we need it, and it's the L-version of an inline type for the VM.

I agree that i made the mistake to talk about "box" to describe my proposal for V*. As Brian said, it's not a box at runtime because it works like an inline type with no identity.

Before decided where to put the cursor, i want to explain why we should not choose the fully functional semantics and why we should not choose the crippled one too.

V* describe a reference, as John said the old contract, if we end up with V* in APIs, we have not improved the Java world because JITs can not see through a V* and we have actually make it worst because V* has all the shortcomings of a reference type and all the shortcomings of an inline class at runtime i.e. no identity. So if we have V* in the API, we loose. We want V* for some use cases but not in the signature of the methods.

Here comes the parallel with Integer, the way we use Integer currently is, i believe, the way we should use V*. It's fine to use V* as a type argument, it's fine to use it in a field if you want the reference semantics or a null value. It's not fine to use Integer as parameter of a method. That's why i think V* should not have the fully crippled semantics, but a kind of in-between.

and i will stop here, because if we don't agree on that, there is no need to go further.

> 
> — John

Rémi