[External] : Re: JEP 405 update

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Gavin Bierman" <gavin.bierman at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, February 9, 2022 11:11:56 PM
> Subject: Re: [External] : Re: JEP 405 update

> Thanks Remi. Yes, this text could be better (interestingly, it is unchanged from
> nearly a year ago!).

I believe it's a direct consequence of this JEP being more readable now that it was before.
It was covering too mush ground at too high level.

> I think you’d agree that *pattern matching* with nested
> patterns provides a null-safe approach to data access, right? 

Not more than the type pattern

Object o = ...
switch(o) {
  case Bar bar -> // bar can not be null here
  default -> ...
}

or

Object o = ...
if o instanceof Bar bar) {
  // bar can not be null here
}

In a sense, the record pattern is an "extension" of the type pattern so like the type pattern it does not allow null (if not total).

BTW, the record pattern is not an extension of the type pattern if the type is total,
It's another clue that the type pattern and totality are two different concepts.

We would not have such issue if the type pattern was separated into two kind of patterns, the type pattern (case Foo foo) that requires an explicit type and the var pattern (case var foo) that is total (again the C# solution).


> That’s really what I am getting at. In that sense, record patterns are a key, because they
> support nesting of patterns. You are correct that the construct within which we
> surface pattern matching can have a say in the top-level treatment of null.

It's not what i've said, the treatment of null is due to the fact that a type pattern (at least the non total one) is semantically an instanceof thus reject null.

> Indeed, one of the things we are discussing at the moment is exactly whether
> switch should have a stronger opinion about top-level null!

yes i know, and i find that idea weird, we should try to make the patterns to behave the same way whatever the container, to not bother users with to many details.

> 
> Let me see if I can work on the text some more.
> 
> Thanks for the feedback,
> Gavin

Rémi

> 
>> On 9 Feb 2022, at 16:40, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Gavin,
>> I don't buy the argument that record patterns promote a null-safe style of
>> programming as this is stated several times in the JEP.
>> 
>> The ""null-safety"" (notice the air quotes) mostly comes from the instanceof or
>> the switch (which semantics is equivalent of a cascade of if instanceof), not
>> from the record pattern by itself.
>> 
>> You can argue that when a record pattern is nested a nullcheck appears, but it's
>> more than the underlying semantics is a degenerated instanceof when the
>> declared type and the instanceof type are the same.
>> 
>> The record pattern is about destructuring after the instanceof/nullcheck has
>> been done, so i find that argument counter productive because it does not help
>> to understand the semantics.
>> 
>> Also, we have talked several times to introduce the record pattern when doing an
>> assignment
>>  Point point = ...
>>  Point(int x, int y) = point;
>>  // can use x and y here !
>> 
>> This will throw a NPE if point is null, similarly to an unboxing operation.
>> 
>> The null-safety is not attached to the record pattern per se but by the
>> container that use it (instanceof, case of a switch, enclosing pattern).
>> 
>> regards,
>> Rémi
>> 
>> ----- Original Message -----
>>> From: "Gavin Bierman" <gavin.bierman at oracle.com>
>>> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>> Sent: Wednesday, February 9, 2022 12:59:02 PM
>>> Subject: JEP 405 update
>> 
>>> Dear experts,
>>> 
>>> Just to let you know that I have updated JEP 405:
>>> 
>>> https://openjdk.java.net/jeps/405
>>> 
>>> You will see that we have removed the array patterns from this JEP (and it has
>>> been retitled accordingly). We're still committed to supporting a direct pattern
>>> form for arrays, but given our tight schedule and a number of queries about the
>>> exact syntactic form for array patterns, we think we'll be better off decoupling
>>> them from JEP 405, and releasing them in a future patterns JEP.
>>> 
>>> Comments welcomed!
> >> Gavin