Is V? what we need ?

[John Rose]

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.

— John