Guards

[Brian Goetz]

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: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210305/73833001/attachment-0001.htm>