Guards redux
John Rose
john.r.rose at oracle.com
Wed Mar 10 21:59:32 UTC 2021
Good. PrimaryPattern is a good concept.
On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>
> Guard:
> : AssignmentExpression
I think it should be this instead:
Guard:
: ConditionalAndExpression
The effects of this narrower definition of a guard expression
are two:
First, any guard of the form (a || b), (a ? b : c), or (a = b)
will require parentheses.
Second, as a result, the following puzzlers will not be legal
inputs:
case P && a || b: // compare x instanceof P && a || b
case P && a ? b : c: // compare x instanceof P && a ? b : c
case P && a = b: // compare x instanceof P && a = b
In all of these puzzlers, the “extremely fortuitous”
correspondence between the syntaxes of guarded
cases and instanceof’s with following boolean logic
are broken.
The fix to align the meanings of the cases with the
instanceof’s is to add parentheses:
case P && (a || b): // compare x instanceof P && (a || b)
case P && (a ? b : c): // compare x instanceof P && (a ? b : c)
case P && (a = b): // compare x instanceof P && (a = b)
Using the modified grammar rule above forces the
coder to write the parentheses, I think.
I think we should aim for “perfectly fortuitous”
here, not just “well, look how often the syntaxes
seem to mean the same thing although sometimes
they don’t”. Indeed, this is my main reason for
plumping for P && g in the first place.
— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210310/4264eeba/attachment-0001.htm>
More information about the amber-spec-experts
mailing list