Feedback: Guards and static/instance pattern declarations

[Brian Goetz]

On 1/24/2021 9:18 AM, Stephen Colebourne wrote:
> The semantic approach of turning boolean expressions into guard
> patterns seems reasonable. But it seems to me that the goal should be
> to integrate boolean expressions and patterns as completely as
> possible, rather than trying to make them disjoint. Currently:
>
> * the use of & is nasty given its meaning of evaluating both sides
> *  true(<booleanExpr>) and false(<booleanExpr>) seem like overkill
> ("new stuff wants to look new")
>
> // this is the current proposal
>   case NumBox(int i) & true(i == 0):
>   case NumBox(int i) & true(i > 6) & true(i < 10):
>
> // this seems much more desirable
>   case NumBox(0):
>   case NumBox(int i) && i > 6 && i < 10:
>   case NumBox(int i) && (i < 6 || i > 10):

Here's a more concrete example of where this approach starts to lose it 
when we get past trivial guards.   If we try to interpret an arbitrary 
boolean expression as pattern, when it is the right operand of a && 
whose left operand is a pattern, what do we do with this:

      t instanceof Foo(var x) && x instanceof Bar(var y) && Q:

`x instanceof Bar(var y)` is surely an allowable boolean expression, but 
now it is really not clear whether the user meant to match t to Foo(var 
x) and to Q, subject to the guard that x is a Bar(var y), or meant to do 
to separate instanceof tests, the second to "Bar(var Y) && Q".

So while in the trivial cases, I can see the desire to let the user be 
"sloppy" and use an expression where a pattern is expected,  and 
automatically make up the difference, when we get outside the trivial 
cases, it gets really hard to understand what the user means.  Instead, 
if we wrap the boolean in a guard:

     t instanceof (Foo(var x) & true(x instanceof Bar(var y)) & Q)

the fact that there is a composite pattern with an embedded 
pattern-match guard becomes more obvious.