Guards redux

[Gavin Bierman]

Thanks everyone for the discussion. I have updated the JEP:

http://openjdk.java.net/jeps/8213076

It proposes *guarded patterns* of the form `p&&e`, as well as parenthesized patterns, written `(p)`.  

I have left out AND and OR patterns, at least for now. Thanks to Guy we now know how to add them elegantly to the grammar when the time comes :-) When people come to play with this, I’d be especially interested to hear about the need for AND and OR patterns. (I have a feeling that OR is more important, but that’s another email...)

Comments on the JEP very welcome.

Thanks,
Gavin


> On 11 Mar 2021, at 13:51, Gavin Bierman <gavin.bierman at oracle.com> wrote:
> 
> 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> wrote:
>> 
>> 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
>> 
>> 
>