[External] : Re: User model stacking

[forax at univ-mlv.fr]

> From: "Kevin Bourrillion" <kevinb at google.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Dan Heidinga"
> <heidinga at redhat.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Thursday, April 28, 2022 3:51:07 PM
> Subject: Re: [External] : Re: User model stacking

> On Thu, Apr 28, 2022 at 9:09 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> So we’re suggesting restacking towards:

>>> - Value classes are those without identity
>>> - Value classes can be atomic or non-atomic, the default is atomic (safe by
>>> default)
>>> - Value classes can further opt into having a "val" projection (name TBD, val is
>>> probably not it)
>>> - Val projections are non-nullable, zero-default — this is the only difference
>>> - Both the ref and val projections inherit the atomicity constraints of the
>>> class, making atomicity mostly orthogonal to ref/val/zero/null

>> Now that the model is clearer, let's try to discuss about the val projection.

> (For the record, I don't think the messages of the last 48 hours have made the
> model "clearer", just floated a lot of possibilities.)

It's clearer to me, the properties of the value types whatever the way we decide to group them are runtime property, not type property. 
Using a L-type instead of a Q-type just add null into the set of possible values. 

> But I do want to say I appreciate you providing all these opposing arguments to
> my proposal (which I asked for!).

> I'm going to engage with your specific arguments, but I don't recall if you ever
> engaged properly with all of mine. I feel like if you took them into account
> also, your overall position might be more balanced? In particular, it is a
> *huge* simplification to be able to say that every class does the exact same
> thing, and some just do extra.

[...] 

See my answers to Brian. 

>> 4/ It's a double opt-in, people have to opt-in at declaration site by asking for
>> a zero-default value type but that is not enough,
>> it only works if the type val is uses at use site. I don't know any feature in
>> Java that requires a double opt-in.

> You have to opt into a class being subclassable, then you have to opt into
> subclassing it.
> There's tons of examples.

subclasseable and subclassing are not the same property. 
Here we are talking about zero-default and zero-default. 

zero-default value class Complex { ... } // opt-in here 

class Holder { 
Complex.val x; // and opt-in here 
} 

You need both otherwise it's not zero-default. 

> I'm not sure that's a good framing anyway. The use-site doesn't really opt in or
> out. The class just opts in to generating two types. Now there are two types
> and clients use those types however they want.

>> 5/ It's easy to forget a ".val". To work, people will have to pepper .val
>> everywhere and it will be easy to miss one occurrence.
>> Depending on where the ".val" is missed, performance will suffer.

> People can come back and purchase that better performance for the price of
> dealing with the safety hazards. imho, this is exactly as it should be.

This is only true if you control the whole code, otherwise you are using a library and the .val that is missing is inside the library. 

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
> kevinb at google.com ]

Rémi