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