On Aug 30, 2021, at 9:08 AM, Brian Goetz
<brian.go...@oracle.com<mailto:brian.go...@oracle.com>> wrote:
This was always the intent. Recall that we discussed cases like:
case IntBox(int x), IntBag(int x):
and backed away not because they were unsound, but because they presented
confusing questions like "where is the declaration of x”.
I think it is reasonable to make a sort of “dead zone”
for x after the OR-pattern (which is introduced
by the comma if you squint right). By that I mean,
“x” is not definitely assigned after the OR-pattern,
which is after the “:”.
That would allow the following guard expression
to use “x” in a place where it has only one candidate
binding:
case IntBox(int x) && isBoxable(x), IntBag(int x):
Then there is the question of whether it would
be possible to design rules that would allow this:
case IntBox(int x) && isBoxable(x), IntBag(int x) && isBaggable(x):
(…Keeping the two bindings of x distinct, and still disallowing
x after the colon.)
But in the end, such fine distinctions do not add much
value, given that alpha-renaming fixes everything:
case IntBox(int x) && isBoxable(x), IntBag(int x2) && isBaggable(x2):
Which leaves me with just one question: Do the rules
allow that last example, or is there a problem with
OR-patterns that carry bindings? After all, it would
seem that OR-patterns with bindings are never useful,
but that “would seem” is wrong, because guards close
to the OR-pattern term are useful.
— John
