<div dir="ltr">I read through some messages about member patterns design and accumulated some thoughts to share.<div><br></div><div>It happened so that all of my recent projects were linked to parsing some data:equations, java statements etc., so I have been on close terms with switch statements during tokenization and syntax tree construction.</div><div><br></div><div>It is common practice in parser development to build either type hierarchies. For older solutions, it is common to just informally "imply" that one type of tokens is a subtype of another and use some field like "kind" as a discriminator. The thing in common in both approaches, is that one "state" of token or ex[ression could be not mutually exclusive to another. Consider following:</div><div><br></div><div>Token</div><div>| - KeywordToken</div><div>| | - ExtendsToken</div><div>| | - SuperToken</div><div>| | ....</div><div>| - LiteralToken</div><div>| | - NumberToken<br></div><div>| | - StringToken</div><div>...</div><div>Also, we have some factory that receives String and returns token:</div><div>class Tokens {</div><div>         Token parse(String s) { .. }</div><div>         static case pattern parseKeyword(String s) { .. } // hope I understood syntax correctly</div><div>         static case pattern parseLiteral(String s) { .. }<br></div><div>         static case pattern parseNumberLiteral(String s) { .. }</div><div>}</div><div><br></div><div>Now, somewhere in the processing pipeline, I decided to use member pattern matching:</div><div>switch (str) {</div><div>          case Tokens.parseLiteral(String literalStr) -> ...</div><div>          case Tokens.parseKeyword(String kwdStr) -> ...<br></div><div>          case null -> ...</div><div>}</div><div><br></div><div>At this point, all possible states are already exhausted. However, If i got everything correctly, this won't compile, as the compiler still thinks parseNumberLiteral is not exhausted, while effectively it is.</div><div><br></div><div>I think such situations could become pretty common. One solution I can think of is to add an option to specify a supercase like  static case pattern parseNumberLiteral(String s) extends parseLiteral { .. }.</div><div><br></div><div>This might seem weird, but, in fact, things like this have been here since the first day of type pattern matching. case String effectively extends case CharSequence and case Object, so I think enabling something like this for custom cases would be reasonable.</div><div><br></div><div>Also, some cases could accept null as valid value. For example, modifying Tokens class like so:<br><div>class Tokens {</div><div>         Token parse(String s) { .. }</div><div>         static case pattern parseKeyword(String s) { .. } // hope I understood syntax correctly</div><div>         static case pattern parseLiteral(String s) { .. }<br></div><div>         static case pattern parseNumberLiteral(String s) { .. }</div><div>         static case pattern nullOrEmpty(String s) { ... }</div><div>}</div></div><div><br></div><div>Now, if we match Tokens.nullOrEmpty(String s), null is also exhausted. Maybe there could be syntax like  static case pattern nullOrEmpty(String s) covers null { ... } or something like this.</div><div><br></div><div>Moreover, null is a special value, so, if we assume there is a nonNull(Object obj) pattern in Objects class, switch like this:</div><div>switch (someVar) {</div><div>           case Objects.nonNull(Object notNull) -> ...</div><div>           case null -> ...</div><div>}</div><div><br></div><div>is also exhaustive for any type.</div><div><br></div><div>That's my concern about this proposal. I really love this feature, I think it could introduce a completely new way of writing code in Java. However, to do so, I think something like this should be present to make pattern matching as smart and flexible as possible.</div><div><br></div><div>Best regards</div></div>