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
"incantation".
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)
__FAIL;
}
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): ...
is?
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 <asviraspossi...@gmail.com>
To: amber-spec-comme...@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
