Composition of pattern questions

[Stephen Colebourne]

On Thu, 4 Mar 2021 at 17:02, Brian Goetz <brian.goetz at oracle.com> wrote:
> >> _two_ features (& composition and true/false patterns) to get to a guard
> >> in a switch seems too roundabout, and you want something more direct?
> > The JEP is already telling you that guards are not the same as other
> > patterns - that they are pattern modifiers, not patterns.
>
> That's an interesting interpretation -- where do you get that from?

"The grammar has been carefully designed to exclude a guard pattern as
a valid top-level pattern. There is little point in writing pattern
matching code such as `o instanceof true(s.length != 0)`. Guard
patterns are intended to be _refine_ the meaning of other patterns.
The grammar reflects this intuition." (now deleted and available via
the history)


>    switch (target) {
>        case Foo(Bar x): A
>        case Foo(Baz x): B
>        case Foo(var x): C
>        case true(configFooOnly): break;
>        case Quux q: D
>        ...
>   }

Nice to have an example that isn't completely contrived. But is it
enough to drive the 95% use case of "I just want a guard" to a more
complex outcome? I think that's a valid stewardship question. Even
when method patterns are added, most users won't come across &
compositions very often. So, it is almost like using & for guards is a
way of forcing them to be less unusual at some point in the future.
I'm not sure that's a great argument for them.


> One day, it occurred to me that, with the ultimate pattern model we are envisioning, we don't need a linguistic notion of guards at all!  I could write an ordinary pattern:
>     static pattern guard(boolean b) {
>         if (!b) __FAIL;
>     }
> and voila, we can express guards as:
>    case P & guard(e)

This is exactly as it appeared to have happened from the list ;-) Thus
another way to look at this discussion is whether it is worth
providing syntax sugar for the future library-based method pattern? We
are both arguing yes (although your take is more driven by schedule
pragmatism). But we have two competing syntaxes for the sugar:

  case P & true(e)
  case P when(e)

The former is indeed much closer to where you might end up with method
patterns. But IMO that isn't normally what sugar is trying to do - I'd
argue that sugar is generally intended to make a concept simpler/more
palatable/prettier, which is why I favour the second one.

When method patterns are added you still get the equivalent of guard
patterns (and as a bonus, a nicer method name), but they only affect
the <5% use case that really needs them. Thus, I'm proposing that
guard patterns are added only as a *library* feature in some future
version of Java with method patterns. Adopting sugar for guards *now*
covers the 95% use case as a *language* feature, and will continue to
be sensible sugar even after method patterns exist (so it's not wasted
effort/syntax). But given that it really is sugar, it should be
properly sugary, thus no &.


> Again, I think your real objection is: "I have to use two language
> features -- a pattern and a combinator -- to express a simple boolean
> filtering."  Yes?

I think it's more that I think guards are important enough to have
their own syntax/sugar. Having to tie together multiple looser
elements doesn't really fit the mental model of the 95% use case.

Stephen


Stephen