Draft JEPs: Pattern Matching for switch and Record Patterns

[Remi Forax]

> From: "Gavin Bierman" <gavin.bierman at oracle.com>
> To: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-dev" <amber-dev at openjdk.org>, "amber-spec-experts"
> <amber-spec-experts at openjdk.org>
> Sent: Monday, October 3, 2022 5:29:40 PM
> Subject: Re: Draft JEPs: Pattern Matching for switch and Record Patterns

> Hi Tagir,
The main objection to remove the name of the record pattern is that it does not follow the principle of the data oriented programming. 
The idea is that the data is more important than the code, or said differently, if the data change by example a component is added to a record, the compiler should flag all the code that uses that record and ask the user to modify the code. 

So a case with a record pattern is better than just a type pattern, because unlike a type pattern, a record pattern validates the shape of a record 
case Point p // does not validate the shape of Point 
case Point(int x, int y) p // validates that a Point has two components x and y. 

When using virtual polymorphism, an operation is defined as an abstract method, so if the record shape changes, people will scan the rest of the record and change the implementation of the methods according to the new components. If the operation uses pattern matching, the record and the operation are not declared at the same place, so the compiler has to help users to find all the locations in the code that should be updated. 

> So it was a number of issues actually. First, there is a nasty ambiguity
> problem. Consider:

> record R(){}
> switch(e) {
> case R() when when (true) -> ...
> ...
> }

> The label could be parsed as either:

> case (R() when) when (true) ->

> or

> case (R()) when (when(true)) ->

> (where ` when ` is a static boolean method).

It's a usual issue with local keywords, we had the same kind of issue with the local keywords inside modules (transitive as a keyword or has a package name). 

A solution on top of my head is to make "when" a keyword for the whole case (everything in between "case" and "->"), so having to consecutive "when" is not syntactically valid. 
It's not the only option, and i don't think it's a showstopper. 

> There is another issue which is this variable declaration is the only one in the
> language that can’t be annotated or marked as `final` which feels like a design
> smell. None of the obvious solutions to this looked good.

For me, a group pattern is not really different than a type pattern for this concern, 
the current syntax is with a type pattern is 
case final Point p -> 
so the syntax for a record pattern is 
case final Point(int x,int y) p -> 

It awkward and super verbose but it's a straight consequence of not having the binding always final. 

> In most other languages with pattern matching they keep these two things - a
> destructing pattern and a naming pattern - separate. In both Haskell and Scala,
> they write `x at p` to “name” a pattern p as x. So that seems like a possibility.
> But for now, we noted that in most cases you can rewrite pretty simply, e.g.

> case Point(var x, var y) when p.isVisible() ->

> can be rewritten:

> case Point p
> when p.isVisible() && p instanceof Point(var x, var y): …

> or if it was in an instanceof:

> if (x instanceof Point p && p.isVisible() && p instanceof Point(var x, var y)) {
> … }

> Neither of these versions read too badly.

I disagree, a case ... does not exist in the vacuum but works and is read with the other cases. 
Here, following "case Point p when ... ", you will have a proper record pattern of Point to be exhaustive and the lack of common prefix between the two patterns makes the code hard to read. 

Point p = ... 
switch(p) { 
case Point p 
when p.isVisible() && p instanceof Point (var x, var y) -> ... 
case Point(int x, int y) -> ... 
} 

compared to 
Point p = ... 
switch(p) { 
case Point(int x, int y) p when p.isVisible() -> ... 
case Point(int x, int y) p -> ... 
} 

Here, it's clear that the first line is a peculiar case of the second line. 

> Thoughts?

> Gavin

Rémi 

>> On 3 Oct 2022, at 14:40, Tagir Valeev < [ mailto:amaembo at gmail.com |
>> amaembo at gmail.com ] > wrote:

>> Hello!

>>> Remove support for named record patterns.

>> This surprises me. Probably there was a discussion about the rationale
>> behind this change? Could you please point me? Thanks.

>> With best regards,
>> Tagir Valeev

>> On Mon, Oct 3, 2022 at 2:48 PM Gavin Bierman < [ mailto:gavin.bierman at oracle.com
>> | gavin.bierman at oracle.com ] > wrote:

>>> Dear all,

>>> The draft JEPs for the next preview of the Pattern Matching for switch and
>>> Record Patterns features are now available at:

>>> Pattern matching for switch: [ https://bugs.openjdk.org/browse/JDK-8294285 |
>>> https://bugs.openjdk.org/browse/JDK-8294285 ]
>>> Record Patterns: [ https://bugs.openjdk.org/browse/JDK-8294078 |
>>> https://bugs.openjdk.org/browse/JDK-8294078 ]

>>> Comments welcomed!
>>> Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221003/16e9a52c/attachment-0001.htm>