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.r...@oracle.com<mailto:john.r.r...@oracle.com>> wrote:
Good. PrimaryPattern is a good concept. On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bier...@oracle.com<mailto:gavin.bier...@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
