It's not safe until it's in the coffer

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 9 Mai 2019 20:30:02
> Objet: Re: It's not safe until it's in the coffer

> Another thing to object to is: the use of pseudo-generics as type operators.
> This raises many new problems: including readability problems (how are readers
> supposed to know that Coffer is a magic fake type, with possibly different
> rules? 

by reading the JLS, it's the same way you know that you can do a += on a Double or call values() on an enum.

> If Coffer accepts primitive args, users would be confused that they can
> say Coffer<int> but not List<int>, etc) and generalized magic-angst (“why can’t
> I write my own type operators.”).

Why do you want Coffer to accept primitive args ?

and i don't get the "why can’t I write my own type operators ?", you can't because you don't control the JLS.
Or are you referencing an old proposal of John about adding an open ended number of postfix type operators, but at that point i'm lost.

What you are trying to express is that the way Coffer works is more similar to a reified generics than our current generics, no ?
In that case the answer is yes, but i don't think it's an issue when we will look at that feature from LW3000 when generics will be reified.

> 
> All that said, I think we’re getting way^3 ahead of ourselves.  I still don’t
> think you’ve adequately outlined what problem you think needs solving; I get
> that you think it would be not-great to use V? types in public APIs, but it’s a
> long leap from there to this proposal.

I would like you to answer honestly to that question, why all inline classes are not always nullable ?
With that model, we are not able to squeeze as much performance as with a non nullable inline class (apart the happy cases where there is at least 1 bit left due to the alignment) but we offer a far simpler model which is one of the Java trademark.

Because if it's okay to have V? types in the public APIs, it's okay to propagate them in between APIs and at that point your performance are not better than using escape analysis. In fact, it's worst because all the spurious NPE that will come from the conversion in between V and V?

So either we go with a complex model and we recognize that V? has to be used with care or perhaps better, we decide that inline class are always nullable (and there is an opt-in to "encode" null in an user-controlled way). 

Rémi

> 
> 
>> On May 9, 2019, at 10:54 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>> 
>> 
>> On 09/05/2019 13:35, forax at univ-mlv.fr wrote:
>>> yes, it's verbose by design.
>> 
>> I object to this a bit.
>> 
>> There will be cases where using nullable projection will be _the only_ way to
>> solve certain problems (e.g. to build value types that can reference to
>> themselves). Forcing an heavy syntax on these cases seems punitive. You seem to
>> assume that, once we have specialized generics, people will just use them and
>> forget about nullable projections. I don't think that's the case, and some
>> internal discussions we started (e.g. to sprinkle values on HashMap
>> implementation) seem to point in that direction too.
>> 
>> Maurizio