Revisiting the rule for merging type patterns ?

[John Rose]

On Aug 30, 2021, at 9:08 AM, Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210831/bec7bc12/attachment-0001.htm>