Positioning of guards (was: Reviewing feedback on patterns in switch)

[Remi Forax]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Tuesday, January 25, 2022 8:49:02 PM
> Subject: Positioning of guards (was: Reviewing feedback on patterns in switch)

>> 2.  Positioning of guards
> 
> We received several forms of feedback over the form and placement of guarded
> patterns.  Recall that we define a guarded pattern to be `P && g`, where P is a
> pattern and g is a boolean expression.  Guarded patterns are never total.  Note
> that we had a choice of the guard being part of the pattern, or being part of
> the `case` label; the current status chooses the former.  (Part of our
> reasoning was that there might be other partial pattern contexts coming, and we
> didn’t want to solve this problem each time. (For intsanceof, it makes no
> difference.) )
> 
> I am prepared to reconsider the association of the guard with the pattern, and
> instead treat it as part of the case.  This is expressively weaker but may have
> other advantages.
> 
> Additionally, people objected to the use of &&, not necessarily because
> “keywords are better”, but because of the potential confusion should we ever
> choose to support switch over boolean, and because the && did not stand out
> enough as turning a total pattern into a partial one.  What the alternative
> looks like is something like:
> 
>    switch (x) {
>        case Foo(var x, var y)
>            when x == y -> A;
>        case Foo(var x, var y) -> B;
>    }
> 
> Here, `when` (bike shed to be painted separately) is a qualifier on the case,
> not the pattern.  A total pattern with a `when` is considered a partial case.
> This simplifies patterns, and moves the complexity of guards into switch,
> where arguably it belongs.
> 
> The loss of expressiveness is in not allowing nested patterns like:
> 
>    P(Q && guard)
> 
> and instead having to move the guard to after the matching construct.  Some
> users recoiled at seeing guards inside pattern invocations; it seemed to some
> like mixing two things that should stay separate.  (For unrolling a nested
> pattern, `case P(Q)` where Q is not total unrolls to `case Pvar alpha) when
> alpha instanceof Q`.)

I think it's a good simplification.

Rémi