Fwd: Two new draft pattern matching JEPs

[Brian Goetz]

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/d254a98d/attachment.htm>