[patterns] Several patterns and guards

[Brian Goetz]

> On Aug 14, 2023, at 9:04 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> On Mon, Aug 14, 2023 at 5:44 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> So, there are two stable points here: make the where clause part of the pattern, or match it with the case label entirely.  The middle option is not stable; a case like
>> 
>>    case P, Q when e:
>> 
>> Is no longer clear
> 
> Exactly, it's no longer clear. This is my point: this syntax is
> allowed now, and people may assume that 'when e' belongs to Q, rather
> than to both patterns. Probably my feeling of English is bad, but to
> me a comma looks like a stronger clause separator than 'when'.

When we went back and forth over whether a guard is attached to a pattern or a case label (and we did this several times), I think we basically made this choice.  When a construct is delimited with multiple keywords, the dependent keyword (else, while, when) is connected to its ancestor (if, do, case).  So case … when … form a pair, and the syntax was chosen to reflect that. 

You are right that whichever way we do it, some people will be confused; `case P, Q when e` could be misunderstood because we’re using two features together.  But I don’t think the answer is to try to cram yet more into switch labels; there’s already a lot (some would say too much) going on there already.  If you want to use multiple patterns with different guards, you can split the patterns into multiple cases. 

> It's ok if it doesn't belong to a pattern (e.g. cannot appear in
> instanceof or inside a deconstruction). Still I'm not sure that the
> middle option (guard belongs to switch label _element_) was thoroughly
> explored. Or probably I've missed the discussion (in this case, I
> would be glad if you pointed me on it). Note that it was irrelevant
> until unnamed variables were introduced, as several patterns in the
> label were syntactically incorrect.

At one point we also explored OR patterns, as in:

    case Foo(int x) || Bar(int x): 

In theory we could give x a meaning here, but people felt that this was too confusing.