Member Patterns -- the bikeshed

[Attila Kelemen]

### Sibling problem of comethods

I would like to have this proposal explicitly address the relationship with
failure handling, because whatever syntax is chosen for pattern matching,
it can prohibit future failure handling syntaxes. Since comethods can be
interpreted as methods returning `UNION{Success(values), Failure}`, where
the `Failure` in pattern matching has only a single possibility (i.e., it
is non-descriptive). While this is okay in some cases, it is quite limiting
in others. Such as: I can imagine a simple `JsonNode.toString` wanting to
use the pattern matching feature, but in this case it is worthwhile to
return additional information in case of failure (what the parser likely
already has available).

Also, while pattern matching is proposed to be used in switches and boolean
conditions there is another use-case that comes up frequently: Matching
failure is catastrophic. In this case, I don't really want the ceremony.
And I would prefer to avoid alternative method names, if a pattern matching
is already available. So, for example the statement (the syntax is not a
proposal, just an simple example):

```
jsonStr instanceof JsonNode.toString(var jsonNode);
```

The above example would throw a `PatternMatchingException`, if the pattern
matching fails.


### Syntax

All of the examples I have seen forces duplicating a lot of information
(return / parameter types, and the name of the method).

Wouldn't it be simpler to just force the comethods to be physically next to
its pair? Even if physical separation would be allowed, a convenient syntax
for the common case when it is not necessary seems very useful to me. That
is, for example (with implicit failure):

```
invertible String commaSeparatedPair(int x, int y) {
  return x + "," + y;
} inverse {
  String[] parts = that.split(",");
  if (parts.length != 2) fail;
  if (
      parts[0] instanceof Integer.toString(var x)
      && parts[1] instanceof Integer.toString(var y)
  ) {
    succeed(x, y);
  }
}
```

Though I have chosen the functional body type for this example, I
personally don't mind the imperative as well. Also, I'm using `that` as an
implicitly declared variable (though I don't care much what a final
version would call it). I can't imagine it would be useful to declare its
name explicitly, since I have never heard anyone saying: "If only I could
declare a different name for `this`.". An additional note that while I have
used "invertible" and "inverse", it is not to deviate from the "pattern"
keyword, I just lacked the imagination of what would be used for
"invertible" if "pattern" is used for "inverse" (and didn't want to think
too much about such minor detail). Though I have to admit that I find the
word "inverse" here a bit misleading, since the method is not a true
inverse in general.

Note that in the above example the keyword `inverse` is not strictly
necessary, but I think it is useful to make the two parts more visually
separate (and also allows Javadoc to be separately declared for the
inverse, if it is deemed to be beneficial to declare separately).

Also, I personally find the `__bind` idea good. I don't think it makes
finding assignments more difficult. In fact, I think it would be good
regardless of the function vs. imperative question, because you could use
that to conveniently declare fall-back values. Such as:

```
int value = 42;
if (!(str instanceof Integer.toString(__bind value))) {
  log.warn("Using fallback value.");
}
```

This of course assumes that a failing pattern method does not change
`value` (which I guess can have consequences for the JIT compiler in an
imperative style).


### Clarification needs

There was a brief mention of "single-abstract-pattern", but I don't see how
it is intended to be used in pattern matching. It seems to me that it would
require some additional syntax burden. Can you clarify the idea?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240401/9dedf340/attachment.htm>