Guards

[Brian Goetz]

I think this is the key observation:
> And because patterns can nest,*this “right edge” can occur placed inside a sub-pattern*, which lets us smuggle guards
> anywhere we like, with a little care:  P&(var x when g(x))&Q.

Our diffidence about a "Patterns + Guards" construct is that forcing all 
the guards to the end seems too constraining; I was never convinced that 
P & G & Q is freely substitutible in practice for P & Q & G (even if the 
differences are only "nonfunctional").  But, if we posit, as Guy did:

     (&&) :: Pattern -> BoolExpr -> Pattern
     (&) :: Pattern -> Pattern -> Pattern

then, using the existing precedence of && and &, then "P and g and Q" 
can be expressed as (P && g) & Q, because (P&&g) is a pattern, which can 
be ANDed with pattern Q. Then:

     if (x instanceof P && g)

parses using existing rules as the boolean expression

     if ( (x instanceof P) && g )

by ordinary operator precedence, and

     if (x instanceof (P && g))

parses as the match of x to the guarded pattern (P && g), which in this 
case is silly but harmless, but may be useful when we are &ing more 
patterns together.  And:

     case P && g:

is an ordinary pattern case with the pattern P-guarded-by-g, no special 
switch magic.

As John says, we don't need & immediately, but there's room for it when 
we need it with the semantics we expect.

What this doesn't give us is a simple form for

     case <boolean expression>

in a pattern switch, but there are plenty of ad-hoc ways to do that:

     case boolean(e):
     case true(e):
     case &&e:
     case if e:
     case _ && e: