Composing patterns and guards

[Brian Goetz]

There are a few reasons we might not want to do this.

1.  Parsing ambiguities.  It would be ideal if the languages recognized by the Pattern production and the Expression production were disjoint.  We’ve eliminated a lot of them, but there are still several, such as `Foo()`.  (If we denoted constant patterns with constant literals, we’d have more.) Even if we could eliminate them all now, it may well constrain the pattern grammar in the future.  

2.  I think it would likely be confusing to humans, even if there were no parsing ambiguities, to have something like 

     x instnaceof P && g && h && Q, since we would have to keep track of whether we were conjoining patterns or expressions.  

3.  To the extent we support switches on booleans, and constant case labels as patterns, things like

    switch (b) { 
        case false && true: 
   }

would be puzzlers.  


> On Jan 18, 2021, at 6:21 PM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> 
> Hi Brian et al.,
> Regarding [1], would it not be possible to turn *any* boolean expression
> into patterns if any cardinality was accepted for targets and outputs.
> 
> As an example, for `line instanceof Line(var point1, var point2) &&
> point1.is(point2)` pattern-composable translation would be similar to `line
> instanceof Line(var point1, var point2) && (point1, point2) instanceof
> GUARD{Point::is}()`.
> 
> I apologize if such an idea has already been raised and I missed it.
> 
> Thanks,
> Mateusz Romanowski
> 
> 
> [1]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-January/002747.html