From forax at univ-mlv.fr  Tue Sep  3 20:41:29 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 3 Sep 2024 22:41:29 +0200 (CEST)
Subject: Null-Restricted and Nullable Types
Message-ID: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>

Hello,
if everybody is okay with that i would like to discuss about Null-Restricted and Nullable Types [1] tomorrow.

There are several points that are not clear to me, i will try to come up with a list for tomorrow.

R?mi

[1] https://openjdk.org/jeps/8303099

From brian.goetz at oracle.com  Tue Sep  3 20:44:03 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 3 Sep 2024 16:44:03 -0400
Subject: Null-Restricted and Nullable Types
In-Reply-To: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>

There are many points that are not clear to us as well, but we will try 
to respond to your questions :)

On 9/3/2024 4:41 PM, Remi Forax wrote:
> Hello,
> if everybody is okay with that i would like to discuss about Null-Restricted and Nullable Types [1] tomorrow.
>
> There are several points that are not clear to me, i will try to come up with a list for tomorrow.
>
> R?mi
>
> [1]https://openjdk.org/jeps/8303099
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240903/cb95040a/attachment-0001.htm>

From forax at univ-mlv.fr  Wed Sep  4 12:36:41 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 4 Sep 2024 14:36:41 +0200 (CEST)
Subject: Null-Restricted and Nullable Types
In-Reply-To: <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
 <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
Message-ID: <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>

Here are my questions: 

1/ Nullness of type variable 
"Like other types, a type-variable type (that is, a use of a type variable) may express nullness. T! is a null-restricted type, and T? is a nullable type." 
- what does 'T' exactly mean ? 
For me, there is the old 'T' which propagate the type but not propagate the nullability and there is the new 'T' that propagate both the type and the nullability of the type. 
During the JVMLS, Dan Smith references them as 'T' and 'T*'. 

2/ If we agree that there are 4 different kinds: String/T, String?/T?, String!/T! and T*, we now have the choice of several user facing models 
- model 1, we let the user annotate using '!', '?' and '*' 
- model 2, we have an opt-in mechanism that set type as '!' by default and type variable as '*' by default. 
- model 3, we only let user to annotate type variable declaration, type of field, type of parameter types/return type, parametrized type (inside the angle brackets) and cast, the rest is inferred 
(this is the semantics of jspecify). 

3/ Nullness of wildcards 
"A type variable declaration or wildcard may have nullness markers on its bounds. A type may satisfy the bounds via nullness conversion, though, so again these nullness markers are not strongly enforced, but may cause warnings." 

=> I see two questions here : 
- unbounded wildcards, they are special because they represent a reified type, so ? is nullable in List<?> because list.add(null) is valid at runtime, thus List<?> is equivalent to List<? extends Object?>. 
Do you agree ? 
- super wildcard, the content of List<? super Foo!> may accept null because Foo? is a super type of Foo!, so List<? super Foo!> is maybe nullable or maybe not, 
so the content is neither a '!' nor a '?'. Do you agree ? 

R?mi 

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Tuesday, September 3, 2024 10:44:03 PM
> Subject: Re: Null-Restricted and Nullable Types

> There are many points that are not clear to us as well, but we will try to
> respond to your questions :)

> On 9/3/2024 4:41 PM, Remi Forax wrote:

>> Hello,
>> if everybody is okay with that i would like to discuss about Null-Restricted and
>> Nullable Types [1] tomorrow.

>> There are several points that are not clear to me, i will try to come up with a
>> list for tomorrow.

>> R?mi

>> [1] [ https://openjdk.org/jeps/8303099 | https://openjdk.org/jeps/8303099 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240904/bd411c76/attachment.htm>

From brian.goetz at oracle.com  Wed Sep  4 13:26:01 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 4 Sep 2024 09:26:01 -0400
Subject: Null-Restricted and Nullable Types
In-Reply-To: <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
 <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
 <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <820ec57b-703d-4914-95f1-5fa638750fcb@oracle.com>

Let's take a step back.? Are you looking for *answers* in the short term 
(say, so you can answer someone elses questions), or are you looking to 
open the dialog about how we will expose nullness for purposes of 
generics migration?? Because there are many, many pages of things to say 
about these questions, not all of which we have answers to, and this 
will significantly affect how we structure the discussion.

On 9/4/2024 8:36 AM, forax at univ-mlv.fr wrote:
> Here are my questions:
>
> 1/ Nullness of type variable
> ? "Like other types, a type-variable type (that is, a /use/ of a type 
> variable) may express nullness. |T!| is a null-restricted type, and 
> |T?| is a nullable type."
> ?- what does 'T' exactly mean ?
> ?? For me, there is the old 'T' which propagate the type but not 
> propagate the nullability and there is the new 'T' that propagate both 
> the type and the nullability of the type.
> ?? During the JVMLS, Dan Smith references them as 'T' and 'T*'.
>
> 2/ If we agree that there are 4 different kinds: String/T, String?/T?, 
> String!/T! and T*, we now have the choice of several user facing models
> ? - model 1, we let the user annotate using '!', '?' and '*'
> ? - model 2, we have an opt-in mechanism that set type as '!' by 
> default and type variable as '*' by default.
> ? - model 3, we only let user to annotate type variable declaration, 
> type of field, type of parameter types/return type, parametrized type 
> (inside the angle brackets) and cast, the rest is inferred
> ??? (this is the semantics of jspecify).
>
> 3/ Nullness of wildcards
> ? "A type variable declaration or wildcard may have nullness markers 
> on its bounds. A type may satisfy the bounds via nullness conversion, 
> though, so again these nullness markers are not strongly enforced, but 
> may cause warnings."
>
> ? => I see two questions here :
> ?? - unbounded wildcards, they are special because they represent a 
> reified type, so ? is nullable in List<?> because list.add(null) is 
> valid at runtime, thus List<?> is equivalent to List<? extends Object?>.
> ???? Do you agree ?
> ?? - super wildcard, the content of List<? super Foo!> may accept null 
> because Foo? is a super type of Foo!, so List<? super Foo!> is maybe 
> nullable or maybe not,
> ???? so the content is neither a '!' nor a '?'. Do you agree ?
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts"
>     <valhalla-spec-experts at openjdk.java.net>
>     *Sent: *Tuesday, September 3, 2024 10:44:03 PM
>     *Subject: *Re: Null-Restricted and Nullable Types
>
>     There are many points that are not clear to us as well, but we
>     will try to respond to your questions :)
>
>     On 9/3/2024 4:41 PM, Remi Forax wrote:
>
>         Hello,
>         if everybody is okay with that i would like to discuss about Null-Restricted and Nullable Types [1] tomorrow.
>
>         There are several points that are not clear to me, i will try to come up with a list for tomorrow.
>
>         R?mi
>
>         [1]https://openjdk.org/jeps/8303099
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240904/915e2751/attachment-0001.htm>

From forax at univ-mlv.fr  Wed Sep  4 14:06:29 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 4 Sep 2024 16:06:29 +0200 (CEST)
Subject: Null-Restricted and Nullable Types
In-Reply-To: <820ec57b-703d-4914-95f1-5fa638750fcb@oracle.com>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
 <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
 <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>
 <820ec57b-703d-4914-95f1-5fa638750fcb@oracle.com>
Message-ID: <1750449966.63590551.1725458789773.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, September 4, 2024 3:26:01 PM
> Subject: Re: Null-Restricted and Nullable Types

> Let's take a step back. Are you looking for *answers* in the short term (say, so
> you can answer someone elses questions), or are you looking to open the dialog
> about how we will expose nullness for purposes of generics migration? Because
> there are many, many pages of things to say about these questions, not all of
> which we have answers to, and this will significantly affect how we structure
> the discussion.
I'm opening the discussion. Those questions are like anchors to me, to try to avoid to go too deep into one of the rabbit holes. 

R?mi 

> On 9/4/2024 8:36 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> Here are my questions:

>> 1/ Nullness of type variable
>> "Like other types, a type-variable type (that is, a use of a type variable) may
>> express nullness. T! is a null-restricted type, and T? is a nullable type."
>> - what does 'T' exactly mean ?
>> For me, there is the old 'T' which propagate the type but not propagate the
>> nullability and there is the new 'T' that propagate both the type and the
>> nullability of the type.
>> During the JVMLS, Dan Smith references them as 'T' and 'T*'.

>> 2/ If we agree that there are 4 different kinds: String/T, String?/T?,
>> String!/T! and T*, we now have the choice of several user facing models
>> - model 1, we let the user annotate using '!', '?' and '*'
>> - model 2, we have an opt-in mechanism that set type as '!' by default and type
>> variable as '*' by default.
>> - model 3, we only let user to annotate type variable declaration, type of
>> field, type of parameter types/return type, parametrized type (inside the angle
>> brackets) and cast, the rest is inferred
>> (this is the semantics of jspecify).

>> 3/ Nullness of wildcards
>> "A type variable declaration or wildcard may have nullness markers on its
>> bounds. A type may satisfy the bounds via nullness conversion, though, so again
>> these nullness markers are not strongly enforced, but may cause warnings."

>> => I see two questions here :
>> - unbounded wildcards, they are special because they represent a reified type,
>> so ? is nullable in List<?> because list.add(null) is valid at runtime, thus
>> List<?> is equivalent to List<? extends Object?>.
>> Do you agree ?
>> - super wildcard, the content of List<? super Foo!> may accept null because Foo?
>> is a super type of Foo!, so List<? super Foo!> is maybe nullable or maybe not,
>> so the content is neither a '!' nor a '?'. Do you agree ?

>> R?mi

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] ,
>>> "valhalla-spec-experts" [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> <valhalla-spec-experts at openjdk.java.net> ]
>>> Sent: Tuesday, September 3, 2024 10:44:03 PM
>>> Subject: Re: Null-Restricted and Nullable Types

>>> There are many points that are not clear to us as well, but we will try to
>>> respond to your questions :)

>>> On 9/3/2024 4:41 PM, Remi Forax wrote:

>>>> Hello,
>>>> if everybody is okay with that i would like to discuss about Null-Restricted and
>>>> Nullable Types [1] tomorrow.

>>>> There are several points that are not clear to me, i will try to come up with a
>>>> list for tomorrow.

>>>> R?mi

>>>> [1] [ https://openjdk.org/jeps/8303099 | https://openjdk.org/jeps/8303099 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240904/61243932/attachment.htm>

From brian.goetz at oracle.com  Wed Sep  4 14:44:05 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 4 Sep 2024 10:44:05 -0400
Subject: Null-Restricted and Nullable Types
In-Reply-To: <1750449966.63590551.1725458789773.JavaMail.zimbra@univ-eiffel.fr>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
 <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
 <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>
 <820ec57b-703d-4914-95f1-5fa638750fcb@oracle.com>
 <1750449966.63590551.1725458789773.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <705caafe-8ffc-4042-a9c0-c75679aadd90@oracle.com>

I appreciate the attempt to avoid the rabbit hole -- but there are just 
so many rabbits!? But let me try to separate the layers.? Each of these 
is a substantial discussion, and we're still gathering our thoughts on 
most of them.

We have to be very careful to separate the notations we use for 
discussing the semantics from notations that are being seriously 
proposed as part of the user model.? Let's assume we are a long way from 
talking about what the surface syntax might look like.

For a use of a type variable, there are four possible ways to combine a 
type variable with nullity information.? Let's call "the argument type" 
the thing the user put in the pointy brackets.

 ?- T! -- the argument type, but null-restricted if it wasn't already
 ?- T? -- the argument type, but explicitly null-allowing if it was 
null-restricted
 ?- T* -- the argument type
 ?- T~ -- the argument type, but of *unknown* nullability

I think we can agree we don't want to burden users with all of these 
fine distinctions; there is a discussion to be had about "what does bare 
T mean", but we should wait.

The reason we even talk about T* vs T~ is because of _migration_. And, 
unlike the migration from non-generic to generic, we have to deal with 
three separate migration scenarios:

 ?- the client wants to use null-marked parameterizations 
(Foo<String!>), but the class has not yet considered nullity 
restrictions (legacy class)
 ?- the class wants to use null markings in its API, but the client is 
not prepared to deal with nullity restrictions (legacy client)
 ?- both client and class are null-aware

So T~ is the type variable equivalent of "I have some old pre-nullity 
code, I have no idea what it thinks the nullity of this type is".

We of course want to get to the point where we get maximal type checking 
in the last stage, but we don't want to put impediments in people's way, 
and are aware that they may take either path. There are many tradeoffs 
here about "more restrictions but sounder type checking" vs "lenient but 
more chances for runtime errors." A strict "flag day" transition from 
"old world" to "new world" on both sides would have simple semantics, 
but would be a horrible experience for users, which would drastically 
slow the uptake of the feature.




On 9/4/2024 10:06 AM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>     *Sent: *Wednesday, September 4, 2024 3:26:01 PM
>     *Subject: *Re: Null-Restricted and Nullable Types
>
>     Let's take a step back.? Are you looking for *answers* in the
>     short term (say, so you can answer someone elses questions), or
>     are you looking to open the dialog about how we will expose
>     nullness for purposes of generics migration?? Because there are
>     many, many pages of things to say about these questions, not all
>     of which we have answers to, and this will significantly affect
>     how we structure the discussion.
>
>
> I'm opening the discussion. Those questions are like anchors to me, to 
> try to avoid to go too deep into one of the rabbit holes.
>
> R?mi
>
>
>
>     On 9/4/2024 8:36 AM, forax at univ-mlv.fr wrote:
>
>         Here are my questions:
>
>         1/ Nullness of type variable
>         ? "Like other types, a type-variable type (that is, a /use/ of
>         a type variable) may express nullness. |T!| is a
>         null-restricted type, and |T?| is a nullable type."
>         ?- what does 'T' exactly mean ?
>         ?? For me, there is the old 'T' which propagate the type but
>         not propagate the nullability and there is the new 'T' that
>         propagate both the type and the nullability of the type.
>         ?? During the JVMLS, Dan Smith references them as 'T' and 'T*'.
>
>         2/ If we agree that there are 4 different kinds: String/T,
>         String?/T?, String!/T! and T*, we now have the choice of
>         several user facing models
>         ? - model 1, we let the user annotate using '!', '?' and '*'
>         ? - model 2, we have an opt-in mechanism that set type as '!'
>         by default and type variable as '*' by default.
>         ? - model 3, we only let user to annotate type variable
>         declaration, type of field, type of parameter types/return
>         type, parametrized type (inside the angle brackets) and cast,
>         the rest is inferred
>         ??? (this is the semantics of jspecify).
>
>         3/ Nullness of wildcards
>         ? "A type variable declaration or wildcard may have nullness
>         markers on its bounds. A type may satisfy the bounds via
>         nullness conversion, though, so again these nullness markers
>         are not strongly enforced, but may cause warnings."
>
>         ? => I see two questions here :
>         ?? - unbounded wildcards, they are special because they
>         represent a reified type, so ? is nullable in List<?> because
>         list.add(null) is valid at runtime, thus List<?> is equivalent
>         to List<? extends Object?>.
>         ???? Do you agree ?
>         ?? - super wildcard, the content of List<? super Foo!> may
>         accept null because Foo? is a super type of Foo!, so List<?
>         super Foo!> is maybe nullable or maybe not,
>         ???? so the content is neither a '!' nor a '?'. Do you agree ?
>
>         R?mi
>
>         ------------------------------------------------------------------------
>
>             *From: *"Brian Goetz" <brian.goetz at oracle.com>
>             *To: *"Remi Forax" <forax at univ-mlv.fr>,
>             "valhalla-spec-experts"
>             <valhalla-spec-experts at openjdk.java.net>
>             *Sent: *Tuesday, September 3, 2024 10:44:03 PM
>             *Subject: *Re: Null-Restricted and Nullable Types
>
>             There are many points that are not clear to us as well,
>             but we will try to respond to your questions :)
>
>             On 9/3/2024 4:41 PM, Remi Forax wrote:
>
>                 Hello,
>                 if everybody is okay with that i would like to discuss about Null-Restricted and Nullable Types [1] tomorrow.
>
>                 There are several points that are not clear to me, i will try to come up with a list for tomorrow.
>
>                 R?mi
>
>                 [1]https://openjdk.org/jeps/8303099
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240904/d30eca5c/attachment-0001.htm>

From forax at univ-mlv.fr  Wed Sep  4 15:30:23 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 4 Sep 2024 17:30:23 +0200 (CEST)
Subject: Null-Restricted and Nullable Types
In-Reply-To: <705caafe-8ffc-4042-a9c0-c75679aadd90@oracle.com>
References: <1949658111.62587211.1725396089114.JavaMail.zimbra@univ-eiffel.fr>
 <98346604-09f9-4b2d-95d7-d3b2f2e0ff75@oracle.com>
 <154950232.63481176.1725453401380.JavaMail.zimbra@univ-eiffel.fr>
 <820ec57b-703d-4914-95f1-5fa638750fcb@oracle.com>
 <1750449966.63590551.1725458789773.JavaMail.zimbra@univ-eiffel.fr>
 <705caafe-8ffc-4042-a9c0-c75679aadd90@oracle.com>
Message-ID: <724583851.63718907.1725463823829.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, September 4, 2024 4:44:05 PM
> Subject: Re: Null-Restricted and Nullable Types

> I appreciate the attempt to avoid the rabbit hole -- but there are just so many
> rabbits! But let me try to separate the layers. Each of these is a substantial
> discussion, and we're still gathering our thoughts on most of them.

> We have to be very careful to separate the notations we use for discussing the
> semantics from notations that are being seriously proposed as part of the user
> model.
yes, this distinction is very important. 

> Let's assume we are a long way from talking about what the surface syntax might
> look like.

> For a use of a type variable, there are four possible ways to combine a type
> variable with nullity information. Let's call "the argument type" the thing the
> user put in the pointy brackets.

> - T! -- the argument type, but null-restricted if it wasn't already
> - T? -- the argument type, but explicitly null-allowing if it was
> null-restricted
> - T* -- the argument type
> - T~ -- the argument type, but of *unknown* nullability

> I think we can agree we don't want to burden users with all of these fine
> distinctions; there is a discussion to be had about "what does bare T mean",
> but we should wait.

> The reason we even talk about T* vs T~ is because of _migration_. And, unlike
> the migration from non-generic to generic, we have to deal with three separate
> migration scenarios:

> - the client wants to use null-marked parameterizations (Foo<String!>), but the
> class has not yet considered nullity restrictions (legacy class)
> - the class wants to use null markings in its API, but the client is not
> prepared to deal with nullity restrictions (legacy client)
> - both client and class are null-aware

> So T~ is the type variable equivalent of "I have some old pre-nullity code, I
> have no idea what it thinks the nullity of this type is".
yes, and I think it can be useful to see T~ and String (raw) the same way, because it makes legacy class code and legacy client code the same thingy. 

> We of course want to get to the point where we get maximal type checking in the
> last stage, but we don't want to put impediments in people's way, and are aware
> that they may take either path.
The drawback of letting too many possible migration paths to the user is that the majority of the users may never reach the maximal type checking. 
If you have several stages, it's not obvious that moving to stage 0 to stage 1, and from stage 1 to stage 2 is easier than moving from stage 0 to stage 2 in one step, this is a classical problem with gradual typing. 

> There are many tradeoffs here about "more restrictions but sounder type
> checking" vs "lenient but more chances for runtime errors."
For me, this is another axis. I think here, we have not a lot of leeway, given we want to support a world with both pre-nullity code and post-nullity code, we have to have null pollution warnings. 
In most cases, this is okay because the pollution does not go far, it stops that the next function call (intra-function). Casting type variables or parametrized types sadly may have inter-functions side effects. 

R?mi 

> On 9/4/2024 10:06 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz 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: Wednesday, September 4, 2024 3:26:01 PM
>>> Subject: Re: Null-Restricted and Nullable Types

>>> Let's take a step back. Are you looking for *answers* in the short term (say, so
>>> you can answer someone elses questions), or are you looking to open the dialog
>>> about how we will expose nullness for purposes of generics migration? Because
>>> there are many, many pages of things to say about these questions, not all of
>>> which we have answers to, and this will significantly affect how we structure
>>> the discussion.
>> I'm opening the discussion. Those questions are like anchors to me, to try to
>> avoid to go too deep into one of the rabbit holes.

>> R?mi

>>> On 9/4/2024 8:36 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>>> Here are my questions:

>>>> 1/ Nullness of type variable
>>>> "Like other types, a type-variable type (that is, a use of a type variable) may
>>>> express nullness. T! is a null-restricted type, and T? is a nullable type."
>>>> - what does 'T' exactly mean ?
>>>> For me, there is the old 'T' which propagate the type but not propagate the
>>>> nullability and there is the new 'T' that propagate both the type and the
>>>> nullability of the type.
>>>> During the JVMLS, Dan Smith references them as 'T' and 'T*'.

>>>> 2/ If we agree that there are 4 different kinds: String/T, String?/T?,
>>>> String!/T! and T*, we now have the choice of several user facing models
>>>> - model 1, we let the user annotate using '!', '?' and '*'
>>>> - model 2, we have an opt-in mechanism that set type as '!' by default and type
>>>> variable as '*' by default.
>>>> - model 3, we only let user to annotate type variable declaration, type of
>>>> field, type of parameter types/return type, parametrized type (inside the angle
>>>> brackets) and cast, the rest is inferred
>>>> (this is the semantics of jspecify).

>>>> 3/ Nullness of wildcards
>>>> "A type variable declaration or wildcard may have nullness markers on its
>>>> bounds. A type may satisfy the bounds via nullness conversion, though, so again
>>>> these nullness markers are not strongly enforced, but may cause warnings."

>>>> => I see two questions here :
>>>> - unbounded wildcards, they are special because they represent a reified type,
>>>> so ? is nullable in List<?> because list.add(null) is valid at runtime, thus
>>>> List<?> is equivalent to List<? extends Object?>.
>>>> Do you agree ?
>>>> - super wildcard, the content of List<? super Foo!> may accept null because Foo?
>>>> is a super type of Foo!, so List<? super Foo!> is maybe nullable or maybe not,
>>>> so the content is neither a '!' nor a '?'. Do you agree ?

>>>> R?mi

>>>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] ,
>>>>> "valhalla-spec-experts" [ mailto:valhalla-spec-experts at openjdk.java.net |
>>>>> <valhalla-spec-experts at openjdk.java.net> ]
>>>>> Sent: Tuesday, September 3, 2024 10:44:03 PM
>>>>> Subject: Re: Null-Restricted and Nullable Types

>>>>> There are many points that are not clear to us as well, but we will try to
>>>>> respond to your questions :)

>>>>> On 9/3/2024 4:41 PM, Remi Forax wrote:

>>>>>> Hello,
>>>>>> if everybody is okay with that i would like to discuss about Null-Restricted and
>>>>>> Nullable Types [1] tomorrow.

>>>>>> There are several points that are not clear to me, i will try to come up with a
>>>>>> list for tomorrow.

>>>>>> R?mi

>>>>>> [1] [ https://openjdk.org/jeps/8303099 | https://openjdk.org/jeps/8303099 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20240904/3492cd19/attachment-0001.htm>

From daniel.smith at oracle.com  Tue Sep 17 16:35:22 2024
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 17 Sep 2024 16:35:22 +0000
Subject: EG meeting *canceled*, 2024-09-18
Message-ID: <D087069E-3003-47ED-A151-8056D5520B8C@oracle.com>

I'll be away tomorrow, so let's cancel the meeting.

We're hard at work on the design for nullness features, working through thorny issues with things like generics and flow analysis (which were kept very vague in the current JEP draft). Hoping to converge towards something in the next few weeks that we can put in the JEP.