<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">(I guess the
pattern should be matching to the original list of record
components, and it isn't related to the constructors. (Or is
it possible that the non-canonical constructors could be used
here?) I presume not, as then a pattern check could have
side effects as well.)<br>
</div>
</div>
</blockquote>
<br>
Currently, records have a single deconstruction pattern -- the one
matching the record descriptor / canonical constructor. But in the
future, records, like other classes, could have more than one
deconstruction pattern, in which case we'd do overload selection
prior to matching.<br>
<br>
Just as with method invocation, first we do overload selection, then
we do what we have to do to convert the arguments to the types of
the parameters. Similarly, with patterns, we do overload selection
(trivial right now with records), and then match the subpatterns to
the bindings. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">record Box(Object content, int size) {}
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">The following
pattern case label won't work: "case Box(i, j) ->" , as "i"
and "j" are not patterns. I see the point to describe the
structure as simply as possible. And given that a single
variable can't be a pattern, it's difficult to cover both the
"Box(i, j)" and a compound "Box(String i, int j)" pattern. But
from the user perspective it would be the most
straightforward.</div>
</div>
</blockquote>
<br>
Our principle here is: variables should be declared. Having i and j
spring into existence by virtual of being named in a pattern, *which
looks an awful lot like a method invocation*, is too subtle. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">If the type
of the components are given (no "overloaded" constructor could
play a role)</div>
</div>
</blockquote>
<br>
As said, this is a short-term state of affairs. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">I saw this
example: "Point(var x, var y) - so this is a special case of
the type pattern, where the component type is inferred. But
why is the "var" necessary here? Isn't it a counterexample,
which breaks the specification, as "var x" isn't a pattern.
Indeed it is very similar to a type pattern, but not exactly
that. (You can't write "case var i ->".)</div>
</div>
</blockquote>
<br>
Because x should have a declaration.<br>
<br>
I realize Python does it differently, but then again, it's
dynamically typed, so it's not really a fair comparison. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">Finally some questions:<br>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">case
Box(Box(String x, int y) a, int z) b -></div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">I haven't
seen a similar example in the JEP, but based on the
description, both the "a" and "b" pattern variables should be
allowed, isn't it? (It would be good.)<br>
</div>
</div>
</blockquote>
<br>
Correct, the inner `Box(String x, int y) a` is what we call a _named
record pattern_. This is not unlike the @ patterns in Haskell or
Scala. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaXYLzThgoeKO_EfsOstZpdSch54ic=z8m76nDZScotntA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">And can we
use a constant as pattern, or the null pattern? For example:</div>
</div>
</blockquote>
<br>
No, not yet. Constants (and null) are not currently patterns.<br>
<br>
<br>
</body>
</html>