I am having trouble understanding the purpose of Unconditional Patterns

[Brian Goetz]

Mostly, the warning is confusing.  In an earlier preview, unconditional patterns were prohibited in instanceof because we were concerned of an asymmetry between `instanceof X` and `instanceof X x`.  The asymmetry was resolved and unconditional patterns were allowed there, but the warning is still a little confusing.

The fact that you all made this delineation meant that it is something worth denoting. Is there some (upcoming) functionality involving pattern-matching that depends on this delineation?

Unconditionality is the basic building block of exhaustiveness (and pattern dominance.)

Note that unconditionality is a stronger condition than exhaustiveness, for reasons that have been explained in other mails.

Why make this delineation for the following snippet, but not the one below it?

if (input instanceof Triple t) {} //error or warning, depending on what you compile with

if (input instanceof Triple) {} //compiles fine and runs fine

These should mean the same thing now.  (Originally it did not, and we were worried this would be confusing, hence the restriction.)  The main place where they didn’t was at null, and finding the right place to handle nullity was among the trickiest aspects of getting this design result.  Now, the construct (instanceof, switch, etc) gets first crack at the target, and gets to have opinions about nulls, and whether/when to proceed and try to match the pattern.   So instanceof first checks for null and short circuits to false in that case, and if not, it tries to match the pattern.  (If the pattern is unconditional on the operand type no runtime test should be generated.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230102/aa83417f/attachment-0001.htm>