Guards redux

[Gavin Bierman]

Very clever, John. Yes, let’s not add any more puzzlers to the language!

On 10 Mar 2021, at 21:59, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

Good.  PrimaryPattern is a good concept.

On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bierman at oracle.com<mailto: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/20210311/7ae48e8a/attachment.htm>