I am having trouble understanding the purpose of Unconditional Patterns

Brian Goetz brian.goetz at oracle.com
Mon Jan 2 17:17:58 UTC 2023


More specifically, we enforce pattern dominance in switch patterns by ensuring that the pattern above is not unconditional for the pattern below.

Essentially yes, though its more subtle than that.  But where unconditionality is really important is in nesting.  Suppose I have

    record Box(Object o) { … }

and

    switch (box) {
        case Box(Object o):  B;

        case Box b: // dead
    }

We can conclude the second pattern is dominated because not only is there a “case Box(…)” above it, but the pattern nested inside it (Object o) is unconditional on the component of Box.  If the first pattern were `case Box(Integer i)`, the `case Box b` would not be dead.

And we can enforce exhaustiveness by making sure the final pattern in switch patterns is the only one that is unconditional on the parameter.

That’s one way to get exhaustiveness, but not the only way.  If I have a sealed type A = B|C, then if the switch exhausts B and C, then it exhausts A, even without any sort of `case A` pattern.

It sounds like the creases have been ironed out at this point between instanceof pattern matching and unconditionality. So why does the warning still exist for instanceof pattern matching?

As I said, the warning is  confusingly worded, and will go away when we exit preview (which is hopefully soon.)


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


More information about the amber-dev mailing list