It starts with a bang ends with a quote

[Remi Forax]

> From: "Clement Cherlin" <ccherlin at gmail.com>
> To: "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.org>
> Sent: Tuesday, May 21, 2024 11:37:35 PM
> Subject: Re: It starts with a bang ends with a quote

> On Tue, May 21, 2024 at 10:30 AM < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> From: "daniel smith" < [ mailto:daniel.smith at oracle.com |
>>> daniel.smith at oracle.com ] >
>>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> valhalla-spec-experts at openjdk.java.net ] >
>>> Sent: Tuesday, May 21, 2024 4:49:30 PM
>>> Subject: Re: It starts with a bang ends with a quote

>>>> On May 21, 2024, at 1:09 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>>> forax at univ-mlv.fr ] > wrote:

>>>> Hello,
>>>> I recently tried to convince myself that using a type annotation (the bang '!')
>>>> was the best way to do type specialization at langage level but I still find it
>>>> awkward.

>>>> There are several reasons why using a bang to ask for type specialization does
>>>> not work well with the rest of the design of value types.

>>> We've considered lots of different variations on specialization, so to be clear:
>>> you're critiquing an approach in which Foo<Val!> is specialized, while
>>> Foo<String> and Foo<Val> are not. Is that right?

>> Not exactly, I think we do not need Foo<Val!> at all.

>>> I think we're going to end up with a stronger requirement: that Foo<Val!> and
>>> Foo<Val> must *both* be specialized. (My inclination has always been to throw
>>> Foo<String> in there, too, but that one is more negotiable.)

>>> Why specialize Foo<Val>? Because we can often still flatten the storage (we're
>>> including some flattening of nullable value class types in JEP 401), and in any
>>> case we should always scalarize specialized method signatures for value class
>>> types.

>> I will go a step further, by example, in most case an immutable list rejects
>> null, so a list created with ImmutableList via List<Val>.of() should be
>> specialized, it's up to the implementation of ImmutableList to decide which
>> kind of storage to use. So it's not something a user should control, thus no
>> List<Val!>, List<Val> is enough. An for the scalarization, i hope that Val +
>> requireNonNull is enough (we can speculate of the fact that a value type is non
>> null).

>> Rémi

> I'm concerned that eliminating ! also eliminates a lot of benefits. There is a
> lot of value in ! other than flattening optimizations: Self-documentation,
> static analysis and (potentially) JVM-enforced runtime non-nullability
> guarantees. If there is no T! then List.of() cannot have the static return type
> List<T!>, which it should.

> I want the ability to refine any type (not just value types) to exclude nulls.
> Flattening value type instances is a JVM performance feature, and is not the
> same as the language feature of non-nullability refinement. I don't see there
> being another way to get the performance feature as a justification for
> dropping the language feature.

Hello Clement, 
currently, T! only have an effect on value types, you can not write String!. 

Tracking nulls, in the type system and/or inserting nullchecks is something useful, but it's a separate discussion. 

BTW, i've recently tested the combo JSpecify annotations + ErrorProne NullAway which is quite nice for the type checking part. 

> Cheers,
> Clement Cherlin

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20240522/11a7db5b/attachment.htm>