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

[Brian Goetz]

>     What exactly do you mean by this?
>
>
> 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.

What you're asking for is cool, but enormous, because it involves 
introducing a new dimension into the programming model -- time. 
Currently, we identify which modifications are binary- or source- 
compatible, and let people make their choices, but the ways in which a 
program has evolved over time is external to the programming model.

Adding a component (and doing nothing else) is technically neither a 
binary- nor source-compatible change.  (Existing constructor invocations 
will fail to link.)  Of course, you can add  a constructor overload for 
the old description -- and soon enough, you'll be able to add a 
deconstructor overload too.

> Then for each code, i can say, i do not care about that new component 
> by adding an any pattern or i care about it, add a binding and 
> change/fix the code using that binding.

The plan for dealing with this is the same as with the constructor: 
write a deconstructor for the old description.  Then all the existing 
match sites will continue to work, and you can use "find usages" to 
decide which ones you want to migrate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221023/e6e2a14a/attachment.htm>