----- Original Message ----- > From: "Gavin Bierman" <[email protected]> > To: "amber-dev" <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Sent: Tuesday, February 28, 2023 5:21:42 PM > Subject: Draft JEPs for Patterns in switch and Record Patterns
> Hello, > > We are planning to finalize the two pattern matching JEPs in JDK 21. Drafts of > these final JEPs are available here: > > Pattern matching for switch: https://openjdk.org/jeps/8300542 > Record patterns: https://openjdk.org/jeps/8300541 > > We're proposing some small changes from the preview versions about to appear > in > JDK 20. These include: > > - We're dropping parenthesized patterns. They were leftover from a previous > version of patterns, and they weren't used very much. They complicate the spec > for not a lot of gain. And reuse parenthesis as the syntax for tuple patterns (whatever it is exactly). > > - We're going to support case labels that are the qualified name of enum > constants, and allow switches over non-enum types to have enum case labels > provided they use the qualified names of the enum constants and these labels > are assignment compatible with the switch type. I wonder if we can not extends the unqualified enum value syntax to any sealed hierarchy that contains an enum with that constant. By example, sealed interface HList permits Cons, Nil {} enum Nil implements HList { NIL } record Cons(int val, HList next) implements HList {} HList list = ... switch(list) { case NIL -> ... // the compiler can replace it by Nil.NIL if there is only one enum value named NIL in the hierarchy ... } Perhaps it's a step too far ? > > - We're dropping the support for record patterns in the header of enhanced for > statements. These will re-appear in a separate forthcoming JEP. I hope that enhanced for and destructuring assignment will have the same semantics. > > Please take a look at these new JEPs and give us your feedback (either on this > list or directly to me). > > Thanks, > Gavin Thanks, Rémi
