Is V? what we need ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 1 Mai 2019 16:12:05
> Objet: Re: Is V? what we need ?

>>> Boxes are not a good thing; they were a necessarily evil that arises from the
>>> fact that primitives are not objects.  But they create many problems of their
>>> own.  I don’t see how “more boxes” is the answer here.
>> 
>> More boxes is a temporary answer until we have fully reified generics because at
>> that point we have generics over value types.
> 
> I agree that we need a plan for how to both be stable in the short term and long
> term.  But I think “temporary” is a fantasy!  Whatever we add now, is part of
> Java forever.  So we should add the types that make sense both now and later.

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.

> 
> Boxes are a temporary crutch; if we decide to go with them, we have to be honest
> — it’s boxes forever, until the end of time.  The V? story is a more stable
> long-term story.  (But if you have a better one, we’re listening.).
> 
>> Here we want to introduce boxes not because value type are not objects but
>> because value types are not nullable objects but T is a nullable object.
> 
> You’re assuming the utility of V? after reification is zero, but that’s not the
> case. For example, suppose ArrayList is reified.  Then the user gets the choice
> of erasure or reification by selecting ArrayList<V?> or ArrayList<V>. Erasure
> has a bad rap, but sometimes it is desirable.

V? as box allow that too. As i said there are two use cases for V?, not yet reified generics is one, backward compat is the other.
Both semantics of V? give you backward compat, but do we we agree that this is a corner case. That why i don't want V? to be too powerful, because once generics are reified, the only use case that stay is backward compatibility, and for that the box semantics is enough.

> 
>> So it's a different kind of box, for a different reason but that it should work
>> like a box because our users are already familiar with the box model.
> 
> I think we have to stop using the word box, because it seems very difficult to
> have a conversation when we’re not agreeing on what “box” means.

yes and no.
Part of the appeal of the proposal is that if we cripple N? so remove the subtyping relation and this is debatable, i think also the capability to call fields/methods on it, the semantics is the same a classical box from the type system POV, you have auto-boxing, overloaded methods are resolved in a second pass (preferring V to V?), etc.
So it's not a box by its runtime capability, it's a nullable value type at runtime, but by how it interacts with the Java type system.

Let's call it a coffer if you prefer, i.e. it's like a box but for our precious value type.

Rémi