Guards redux

Gavin Bierman gavin.bierman at
Thu Mar 11 13:51:18 UTC 2021

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<mailto:john.r.rose at>> wrote:

Good.  PrimaryPattern is a good concept.

On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bierman at<mailto:gavin.bierman at>> wrote:

: AssignmentExpression

I think it should be this instead:

: 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

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: <>

More information about the amber-spec-experts mailing list