Feedback: Guards and static/instance pattern declarations

[Brian Goetz]

On 1/28/2021 5:45 PM, Stephen Colebourne wrote:
> On Thu, 28 Jan 2021 at 19:19, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 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".
>  From this, I understand that the main problem is how to determine
> which target applies to Q - t or x.

That's not even really the main problem, though that's surely a problem 
that pops out of this particular example.  My point is a broader one, 
which is that, while P&&e is fine as a pattern combinator when there's 
just one pattern and expression, it becomes much harder to disentangle 
what is going on when it's P && e && Q && f, even if the compiler can 
figure out a way to parse it.  The desire to "get rid of the noise" 
(which works fine in trivial cases) creates a bigger problem, which 
makes the code much harder to read.  The cure is to be explicit about 
the boundary between "pattern world" and "expression world."