<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">There's a lot here, so let me try to
separate. </font><br>
<br>
<div class="moz-cite-prefix">On 4/1/2024 11:07 AM, Attila Kelemen
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAKDaPBe8__4Jp9yPirsyZf36wMQXNSxoZH8PL_-XkFQ94No-LQ@mail.gmail.com">
<div dir="ltr">### Sibling problem of comethods<br>
<br>
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).<br>
</div>
</blockquote>
<br>
This is not really related to the "sibling problem", though; it is
orthogonal. <br>
<br>
The one-bit failure channel is indeed a potential limitation; when
there is a complex nested pattern, it might be useful to be able to
debug "why did this big pattern fail." Not a problem for simple
type and record patterns, but as we have more opportunities to
compose patterns (imagine: matching an entire JSON document in one
big pattern), debugging "why didn't it match" could benefit from
more context. <br>
<br>
So noted: when making syntactic choices surrounding failure, try not
to foreclose on future extension that might carry additional
failure-related information. <br>
<br>
<blockquote type="cite" cite="mid:CAKDaPBe8__4Jp9yPirsyZf36wMQXNSxoZH8PL_-XkFQ94No-LQ@mail.gmail.com">
<div dir="ltr">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):<br>
<br>
```<br>
jsonStr instanceof JsonNode.toString(var jsonNode);<br>
```<br>
<br>
The above example would throw a `PatternMatchingException`, if
the pattern matching fails.<br>
</div>
</blockquote>
<br>
What you are looking for is the ability to combine the effects of a
match (binding the components) with an assertion that the match must
succeed, so that you can assert that any failures are "unexpected"
and can be handled implicitly by the runtime. We considered
something like this under the guise of a `let` or `match` statement,
which is on hold pending a more disciplined analysis of totality
requirements for pattern bodies, and may come back after that.<br>
<br>
Again, this is an orthogonal problem (and we are working hard to
avoid loading the requirements up with "wish list" items, because
otherwise we'll never ship anything.) <br>
<br>
<blockquote type="cite" cite="mid:CAKDaPBe8__4Jp9yPirsyZf36wMQXNSxoZH8PL_-XkFQ94No-LQ@mail.gmail.com">
<div dir="ltr">### Syntax<br>
<br>
All of the examples I have seen forces duplicating a lot of
information (return / parameter types, and the name of the
method).<br>
<br>
Wouldn't it be simpler to just force the comethods to be
physically next to its pair? </div>
</blockquote>
<br>
The "with inverse" suggestion is one we explored (and something
similar was explored in the "JMatch" exploration (Liu and Myers,
various publications.)) It has a few serious problems:<br>
<br>
- It is not like anything else in the language, nor is it a
mechanism that seems likely applicable to other situations, which
have the effect of making it appear "nailed on the side". We are
used to members having stand-alone declarations. <br>
- Since not every pattern is going to be the dual of an actual
method, we still need a full-blown syntax for declaring patterns, in
which case this just becomes a "weird shorthand" for a common case.<br>
<br>
(The same argument was in play in deciding against declaring an
exhaustive group of patterns with a single header.) <br>
<br>
<blockquote type="cite" cite="mid:CAKDaPBe8__4Jp9yPirsyZf36wMQXNSxoZH8PL_-XkFQ94No-LQ@mail.gmail.com">
<div dir="ltr">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?</div>
</blockquote>
<br>
Lambdas. A SAM interface is one with a single abstract method, and
we extract the function shape and use it as a target type for
lambdas. Similarly, a SAP interface is one with a single abstract
pattern. We can play the same game, except the shape is (match
candidate) -> { pattern body that binds declared bindings }.
This allows APIs to be extend with patterns, such as a `match`
method in streams:<br>
<br>
objects.stream().match(e -> e instanceof String s)....<br>
<br>
where Stream::match takes a SAP interface with a single binding,
such as:<br>
<br>
interface Matchy<T, U> { <br>
pattern(T that) p(U u);<br>
}<br>
...<br>
// in Stream<br>
<U> Stream<U> match(Matchy<T,U> m);<br>
<br>
<br>
<br>
</body>
</html>