Hi Tagir,
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).
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.
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@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.
Thoughts?
Gavin
On 3 Oct 2022, at 14:40, Tagir Valeev
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
Record Patterns: https://bugs.openjdk.org/browse/JDK-8294078
Comments welcomed!
Gavin
