Fwd: Two new draft pattern matching JEPs

Brian Goetz brian.goetz at oracle.com
Thu Mar 4 18:19:19 UTC 2021

Lots of people (Remi here, VictorN on a-comments, StephenC on a-dev) are 
complaining about true/false patterns, but my take is that we've not 
really gotten to the real objections; instead, I'm seeing mostly 
post-hoc rationalizations that try and capture the objections 
(understandable), but I don't think we've really hit the mark yet.  As 
I've said, I believe there might be something "there" there, but the 
arguments made so far have not yet captured it, so I don't really know 
how to proceed.  But, clearly this has pushed people's buttons, so let's 
try to drill in.

One possible objection is indirectness / discoverability; that to refine 
a pattern, you have to find some other pattern that captures the 
refinement, and combine them with an operator that isn't used for 
anything else yet.  This contributes to making it feel like an 

Another possible object is more superficial, but may be no less real.  I 
had a private exchange with AndreyN, which revealed two potentially 
useful bits of information:

  - It's possible that the bad reaction to true(e) is that, because 
we're so wired to seeing `true` as a constant, the idea of seeing it as 
a method/pattern name is foreign;

  - Because true is a reserved identifier, the possibility to later pull 
back the curtain and say "look, true(e) is not magic, it's just a 
statically imported declared pattern!" is limited. So by picking 
true/false now, we miss an opportunity to unify later.

So, here's a thought experiment, not so much as a concrete proposal, but 
as a "how does this change how we think about it" query; imagine we 
picked another identifier, with the plan of ultimately exposing it to be 
just an ordinary method pattern later. I'll use the obviously stupid 
"grobble" in this example, to avoid inclinations to paint the shed.  So 
you'd write:

     case Foo(var x, var y) & grobble(x > y): ...

and in Java 17, "grobble" would be specified to be an ad-hoc guard 
pattern, but in Java N > 17, we would be able to pull back the curtain 
and say "behold, the long-hidden declaration of grobble, which we've 
conveniently static-imported for you":

     static pattern(void) grobble(boolean expr) {
         if (!expr)

This would allow us to borrow from the future, while allowing the 
temporary hack to be turned into something legitimate later.

So, control question: if we had said "grobble" instead of "true", does 
that change the perception of how ugly, foreign, or roundabout

     case Foo(var x, var y) & grobble(x > y): ...


Direct answers only, initially.

On 3/4/2021 12:05 PM, Brian Goetz wrote:
> Received on the -comments list.
> Analysis from the legislative analyst:
> This comment amounts to "Well, if you could eventually write the 
> true/false patterns as declared patterns which ignore their target, 
> then just do declared patterns now, and just make them declared 
> patterns."  (Which is exactly what kicked off this direction -- that 
> guards could be expressed as declared patterns which ignore their 
> target.)
> When lumping the features together for a delivery, there's a balance 
> to be struck, of delivering incremental value vs delivering the entire 
> story at once.  The JEPs proposed at this point are pretty close to 
> being a useful increment of value without overly constraining the 
> remainder of the story, but guards are an area where it is tempting to 
> "borrow from the future." Of course if we could do everything at once, 
> we wouldn't be worrying about balancing the short term with the long. 
> But, delaying further pattern matching progress until we have a full 
> story for declared patterns seemed a bit extreme.
> So it's not that we missed that route -- indeed, that's the route that 
> got us to the current position -- it's just that route was rejected as 
> "would delay delivering real value now."
> -------- Forwarded Message --------
> Subject: 	Re: Two new draft pattern matching JEPs
> Date: 	Thu, 4 Mar 2021 17:34:15 +0100
> From: 	Victor Nazarov <asviraspossible at gmail.com>
> To: 	amber-spec-comments at openjdk.java.net
> Hello Java experts,
> I've been following the discussion about new JEPs for pattern matching and
> I've observed a controversy considering the introduction of Pattern 
> guards.
> It seems that what Brian Goetz stated as a problem is:
>>   * either we
>>     don't provide a way to write guarded patterns now (which is not a
>>     problem for instanceof, but is for switch), or
>> * we nail some bit of terrible syntax onto the switch that we're stuck
> with.
> But from my understanding this misses another route:
>> We've already discussed how some patterns (e.g., regex) will take input
>> arguments, which are expressions.  We haven't quite nailed down our
>> syntactic conventions for separating input expressions from output
>> bindings, but the notion of a pattern that accepts expressions as input
>> is most decidedly not outside the model.
> When patterns with arguments become available users are able to write code
> like the following (with imaginary syntax).
> ````
> String s = "aabb";
> String result = switch (s) {
> case String.["(a+)(b+)"]matches(var as, var bs) -> bs + as;
> default -> "no match";
> }
> ````
> Having this ability nothing prevents users to define a `guard` pattern in
> their library and to use it like:
> ````
> case Rectangle(Point x, Point y) & Utils.[x > 0 && y > 0]guard()
> ````
> For me it seems a good solution to introduce a more general mechanism
> (patterns with input arguments) and use it to define a library `guard`
> pattern then to nail some additional syntax (true/false overload).
> So returning to the original problem then I think a possible solution 
> is to
> introduce some special `guard` library pattern right away.
> Cons:
> * Need to decide on special syntax for input arguments right away
> * Hard to specify that custom patterns with input arguments are not yet
> available and only special library `guard` patterns can use this feature.
> Pros:
> * Less special syntax in the language, because input arguments are going
> to be introduced anyway
> * It is probably easier to explain to users the usefulness of `&` because
> that way users can already see that not only destructuring pattern are
> going to be available, but more generic and complex patterns with input
> arguments are going to be available.
> --
> Victor Nazarov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210304/ac4bb573/attachment-0001.htm>

More information about the amber-spec-experts mailing list