On May 1, 2019, at 7:50 AM, Brian Goetz <brian.go...@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. — John
