Draft Spec for Fourth Preview of Pattern Matching for Switch (JEP 433) and Second Preview of Record Patterns (JEP 432) now available

[Dan Smith]

> On Oct 27, 2022, at 3:03 PM, forax at univ-mlv.fr wrote:
> 
> ----- Original Message -----
>> From: "daniel smith" <daniel.smith at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Gavin Bierman" <gavin.bierman at oracle.com>, "amber-spec-experts"
>> <amber-spec-experts at openjdk.java.net>
>> Sent: Thursday, October 27, 2022 11:51:23 PM
>> Subject: Re: Draft Spec for Fourth Preview of Pattern Matching for Switch (JEP 433) and Second Preview of Record
>> Patterns (JEP 432) now available
> 
>>> On Oct 22, 2022, at 2:52 PM, forax at univ-mlv.fr wrote:
>>> 
>>> If i modify a record by adding a new component, i want to compiler to help me to
>>> find all the switches that are using that record so i can re-evaulate if the
>>> new component play a role or not for each of those codes.
>> 
>> Maybe I'm missing something, but doesn't it do this already?
> 
> yes, but with the proposed semantics, it's not possible to extract the record instance AND have the length of the record component list checked.
> 
> Either i can use
>  case Point p -> 
> 
> or
>  case Point(var x, var y) -> 
> 
> but this is not valid anymore
>  case Point(var x, var y) p -> ...

Can always do this, right?

case Point p where p instanceof Point(var x, var y) ->