----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Brian Goetz" <[email protected]> > Cc: "Remi Forax" <[email protected]>, "valhalla-spec-experts" > <[email protected]> > 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 <[email protected]> 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
