<div dir="ltr">

<div>Good summary!</div><div><br></div><div>As always, I have strong opinions and suggestions on how to improve just about everything.<br></div><div><br></div><div># Use-site syntax</div><br>## Deconstruction<br><br>if (let MyClassWithDeconstructor(var a, var b) = myThing) { ... }<br><br>switch (myThing) {<br>    case MyClassWithDeconstructor(var a, var b) -> ...<br>}<br><br>## Static<br><br>if (MyClass.staticPattern(var a, var b) matches someThing) { ... }<br><br>switch (someThing) {<br>    case MyClass.staticPattern(var a, var b) -> ...<br>}<br><br>## Instance / Bound<br>If someThing's static type is not MyClass:<br><br>if (MyClass.instancePattern(var a, var b) matches someThing) { ... }<br><br>switch (something) {<br>    case MyClass.instancePattern(var a, var b) -> ...<br>}<br><br>Or, if the object's static type is known to be MyClass:<br><br>if (myThing.instancePattern(var a, var b)) { ... }<br><br>or<br><br>if (instancePattern(var a, var b) matches myThing) { ... }<br><br>switch (myThing) {<br>    case instancePattern(var a, var b) -> ...<br>}<br><br>## Unbound<br><br>PatternMatcher<MyClass> matcher = MyClass::myPattern;<br><br>if (matcher.match(var a, var b) matches someThing) { ... }<br><br>switch (someThing) {<br>    case matcher.match(var a, var b) -> ...<br>}<br><br># Identifying a member as a pattern<br><br>The

 "pattern" keyword is fine, as long as it's sufficiently contextual to 

not break existing usages. For example, `Pattern pattern = 

Pattern.compile("...")` should still be a valid field declaration. # Position of match candidate None of the above! As previously suggested: static<A, B> pattern of(A a, B b : Optional<T>) # Naming of match candidate I think always using "that" is fine. # Body types I agree with the suggested functional, implicit failure, return means fail. However,

 I see no need for "match" to take "patternName"[1]. The more concise 

`match(BINDINGS)` is preferable to `match patternName(BINDINGS)`.<br><br>Indeed,

 `return` for failure and `return BINDINGS` for success would work just 

as well, except in the case of a degenerate pattern with no bindings, which could 

`return true` for success and `return` or `return false` for failure.[2]<br><br># Exhaustiveness<br><br>The

 `case` modifier is fine, but the design should leave room for `case LABEL` or `case (LABEL1, LABEL2)` to delineate 

membership in exhaustive set(s), as a potential future enhancement.<br><br>[1] Java already has enough gratuitous repetition in class declarations.<br><br><div>[2]

 Sorry, Brian, but member patterns *are* basically "conditional 

var-return methods". The more the design leans into that, the better. In

 my opinion, of course.</div><div><br></div><div># Bonus Gratuitous Perl Advocacy<br></div><div>Alternative spelling suggestion for `a matches b`: `a =~ b`</div><div>Alternative spelling suggestion for `!(a matches b)`: `a !~ b`<br></div><br>Cheers,<br>Clement Cherlin

</div>