<div dir="ltr"><div>Amber devs,</div><div><br></div><div>For the Patterns available to us in Java 21 it has been noted that:</div>1) TypePatterns match unconditionally, that is to say they are "null matching". Meanwhile RecordPatterns at most match exhaustively leaving null valued ReferenceTypes in the remainder, that is to say RecordPatterns are "non-null matching" or "instance matching".<br><br>2) It's the "null hostility" of the "switch" and "instanceof" operators that prevents TypePatterns from matching/dominating the null values there:<br><div><br></div><div>* In the case of "switch" a null valued ReferenceType selector expression will cause a NullPointerException to be thrown by the  switch operator unless the "case null" switch label has been declared in its switch block.</div><div><br></div><div>* In the case of "instanceof" evaluation, when the the RelationalExpression is null valued, null is interpreted semantically as "not an instance" and thus also as "not an instance of" the ReferenceType (or Pattern) found to the right of the "instanceof" keyword.</div><br><br>This dichotomy between TypePatterns and RecordPatterns illustrates a gap in current pattern matching coverage wherein we cannot match null vs non-null vs nullable for non-record ReferenceTypes.<br><br>I would love to see this gap closed.<br><br><div>In JEP 455, I can see there's a lot of work going into making 
Patterns work well with PrimitiveTypes, is anyone looking into 
making Patterns work better with these ReferenceTypes?<br></div><br>What are your thoughts on closing this pattern matching coverage gap and maybe implementing something like the following:<br><br>The current Java 21 Pattern definitions look like<br><div><br><span style="font-family:monospace">Pattern:<br>    TypePattern<br>    RecordPattern</span><br><br>The TypePattern part could be deconstructed and extended giving new Pattern definitions that look more like:<br><br><span style="font-family:monospace">Pattern:<br>    PrimitivePattern (PrimitiveType)<br>    RecordPattern    (non-null valued record ReferenceType)<br>    InstancePattern  (non-null valued ReferenceType)<br>    NullPattern      (null valued ReferenceType)<br>    ReferencePattern (ReferenceType)</span><br><br>Notes:<br>1) The InstancePattern matching a ReferenceType T and the NullPattern matching that same ReferenceType T are complements of each other and exhaustively cover the match space of a ReferencePattern matching that same ReferenceType T<br><br>2) The ReferencePattern matching a ReferenceType T dominates both a NullPattern and a InstancePattern matching that same ReferenceType T<br><br>3) The RecordPattern matching a record ReferenceType T for a Record declared with a zero-arg constructor exhaustively covers the InstancePattern matching that same ReferenceType T<br><br>4) The InstancePattern matching a record ReferenceType T dominates a RecordPattern matching that same ReferenceType T<br><br>Sample of proposed Pattern notation:<br><br><span style="font-family:monospace">match-only Pattern notation:<br>    PrimitivePattern: int<br>    RecordPattern:    Bat(_,_)<br>    InstancePattern:  Bat()<br>    NullPattern:      null<br>    ReferencePattern: Bat</span><br><br><span style="font-family:monospace">match+projection Pattern notation: <br>    PrimitivePattern: int ii<br>    RecordPattern:    Bat(_,_) bb<br>    InstancePattern:  Bat() bb<br>    NullPattern:      null bb<br>    ReferencePattern: Bat bb</span><br><br>(When matched, the pattern's named variables are projected into the appropriate declaration scope)<br><br>Proposed Pattern appearance and idiomatic familiarity:<br>    PrimitivePattern: Resembles a local PrimitiveType variable declaration<br>    RecordPattern:    Resembles an "all-args" constructor call for a record ReferenceType<br>    InstancePattern:  Resembles a "no-args" constructor call for a ReferenceType<br>    NullPattern:      Resembles a ReferencePattern where the ReferenceType has been replaced with the NullLiteral<br>    ReferencePattern: Resembles a local ReferenceType variable declaration<br><br>Does this notation feel good and Java-ish to you? Have you already got something better figured out? Your thoughts?<br><br>Thanks for your consideration,<br>-Steffen</div></div>