Remi Forax forax at
Tue Mar 9 18:32:08 UTC 2021

Apart from what have said about letting grobble to fully access to the bindings, 
i think that using parenthesis to call grobble here is already too much. 

case Foo(var x) when x > y 
is far more readable than 
case Foo(var x) when (x > y) 
because for a pattern the parenthesis describes a notion of ownership, you are describing the content of the type using a destructuring pattern, while the second pair of parenthesis is a kind of method call. 

Having two pairs of parenthesis with two complete different meanings is something is hope you can avoid, at least for the simple cases. 


> De: "Brian Goetz" <brian.goetz at>
> À: "amber-spec-experts" <amber-spec-experts at>
> Envoyé: Vendredi 5 Mars 2021 20:14:01
> Objet: Guards

> Let me try and summarize all that has been said on the Guards topic.

> #### Background and requirements

> For `instanceof`, we don't need any sort of guard right now (with the patterns
> we have); we can already conjoin arbitrary boolean expressions with `&&` in all
> the contexts we can use `instanceof`, because it's a boolean expression. (This
> may change in the future as patterns get richer.) So we can already express our
> canonical guarded Point example with

> if (p instanceof Point(var x, var y) && x > y) { ... }

> with code that no one will find confusing.

> For switch, we can't do this, because case labels are not boolean expressions,
> they're some ad-hoc sub-language. When the sub-language was so limited that it
> could only express int and string constants, this wasn't a problem; there was
> little refinement needed on `case "Foo"`.

> As we make switch more powerful, we face a problem: if the user drifts out of
> the territory of what can be expressed as case labels, they fall off the cliff
> and have to refactor their 50-way switch into an if-else chain. This will be a
> really bad user experience. Some sort of escape hatch to boolean logic buys us
> insurance against this bad experience -- as long as you can express your
> non-pattern criteria with a boolean expression (which is pretty rich), you
> don't have to leave switch-land.

> So we took as our requirement:

> Some sort of guard construct that is usable in switch is a forced move.

> #### Expressing guards in switch

> There are several ways to envision guards:

> - As patterns that refine other patterns (e.g., a "true" pattern)
> - As an additional feature of "case" in switch (e.g., a "when" clause)
> - As an imperative control-flow statement usable in "switch" (e.g., "continue")

> We've largely rejected the third (even though it is more primitive than the
> others), because we think the resulting code will be much harder to read and
> more error-prone. We've bounced back and forth between "let's nail something on
> the side of switch" and "let's let the rising pattern tide lift all conditional
> constructs."

> Other languages have demonstrated that guards in switch-like constructs are
> viable.

> The argument in favor of nailing something on the side of switch is that it is
> pragmatic; it is immediately understandable, it raises the expressivity of
> `switch` to where `if` already is, and it solves the immediate requirement we
> have in adding patterns to switch.

> The argument against is that it is not a primitive; it is dominated by the
> option of making patterns richer (by adding boolean patterns), it is weak and
> non-compositional, and overly specific to switch. (It is possible to make
> worse-is-better arguments here that we should do this anyway, but it's not
> really possible to seriously claim better, despite attempts to the contrary.)

> #### Interpreting the feedback

> The JEP proposes a powerful and compositional approach:

> - true/false patterns that accept arbitrary boolean expressions (and which
> ignore their target);
> - combining patterns with a pattern-AND combinator

> On the one hand, this is a principled, orthogonal, compositional, expressive,
> broadly applicable approach, based on sensible primitives, which will be usable
> in other contexts, and which anticipate future requirements and directions.

> On the other hand, there has been a pretty powerful emotional reaction, which
> could be summarized as "sorry, we're not ready for this degree of generality
> yet with respect to patterns." This emotional reaction seems to have two
> primary components:

> - A "who moved my cheese" reaction to the overloading of `true` in this way --
> that `true` seems to be, in everyone's mind, a constant, and seeing it as a
> pattern is at least temporarily jarring. (This may be a temporary reaction, but
> there's still a cost of burning through it.)

> - A reaction to "borrowing & from the future" -- because the other use cases for
> &-composition are not obvious or comfortable yet, the use of &-composition
> seems foreign and forced, and accordingly engenders a strong reaction.

> The former (which I think is felt more acutely) could be addressed by taking a
> conditional keyword such as `when` here; ad-hoc "focus" research suggests the
> negative reaction here is lower, but still there.

> The latter is, I think, the more linguistically significant of the two; even
> though there is a strong motivation for & coming down the pike, this is not the
> gentle introduction to pattern combination that we'd like, and developer's
> mental models of patterns may not be ready. Patterns are still new, and we'd
> like for the initial experience to make people want more, rather than scare
> them with too much up front.

> #### Options

> I suspect that we'd get a lot of mileage out of just renaming true to something
> like "when"; it avoids the "but that's not what true is" reaction, and is
> readable enough:

> case Foo(var x) & when(x > 0):

> but I think it will still be perceived as "glass half empty", with lots of "why
> do I need the &" reactions. And, in the trivial (but likely quite common, at
> least initially) case of one pattern and one guard, the answers are not likely
> to be very satisfying, no matter how solidly grounded in reality, because the
> generality of the compositional approach is not yet obvious enough to those
> seeing patterns for the first time.

> I am not compelled by the direction of "just add guards to switch and be done
> with it", because that's a job we're going to have to re-do later. But I think
> there's a small tweak which may help a lot: do that job now, with only a small
> shadow of lasting damage:

> - Expose `grobble(expr)` clauses as an option on pattern switch cases;

> - When we introduce & combination (which can be deferred if we have a switch
> guard now), plan for a `grobble(e)` pattern. At that point,

> case Foo(var x) grobble(x > 0):

> is revealed to be sugar for

> case Foo(var x) & grobble(x > 0):

> As as bonus, we can use grobble by itself in pattern switches to incorporate
> non-target criteria:

> case grobble(e):

> which is later revealed to be sugar for:

> case Foo(var _) & grobble(e):

> The downside here is that in the long run, we have something like the C-style
> array declarations; in the trivial case of a single pattern with a guard, you
> can leave in the & or leave it out, not unlike declaring `int[] x` vs `int
> x[]`. Like the "transitional" (but in fact permanent) sop of C-style
> declarations, the "optional &" will surely become an impediment ("why can I
> leave it out here, but not there, that's inconsistent").

> All that said, this is probably an acceptable worse-is-better direction, where
> in the short term users are not forced to confront a model that they don't yet
> understand (or borrow concepts from the future), with a path to
> sort-of-almost-unification in the future that is probably acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list