[patterns] Several patterns and guards
Brian Goetz
brian.goetz at oracle.com
Tue Aug 15 16:04:01 UTC 2023
> 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.
More information about the amber-spec-experts
mailing list