<div dir="auto"><div>Hi, Remi!<div dir="auto"><br></div><div dir="auto">Not mentioning the type name at the use site will greatly reduce IDE performance for find usages functionality. Imagine, one wants to find the uses of a particular record component. Now, we can use identifier index to quickly find all the files that mention the record name, and perform more detailed search on this much smaller subset of files. In your proposed syntax, (var a, var b) = foo().bar() is completely opaque. To understand which record is used here, we need to perform full resolve and type inference for foo() and bar(), which may depend on content of other source files, so we cannot use only content of the current file as a cache dependency.</div><div dir="auto"><br></div><div dir="auto">We already have a huge problem when searching for functional interface implementations (i.e. all the lambdas and method references that implement it). The functional interface is usually not mentioned explicitly near the lambda, so such a search is extremely slow on big projects.</div><div dir="auto"><br></div><div dir="auto">With best regards, </div><div dir="auto">Tagir Valeev </div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jan 14, 2026, 19:17 Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Gavin Bierman" <<a href="mailto:gavin.bierman@oracle.com" target="_blank" rel="noreferrer">gavin.bierman@oracle.com</a>><br>
> To: "amber-spec-experts" <<a href="mailto:amber-spec-experts@openjdk.java.net" target="_blank" rel="noreferrer">amber-spec-experts@openjdk.java.net</a>><br>
> Sent: Saturday, January 10, 2026 12:08:05 AM<br>
> Subject: Amber features 2026<br>
<br>
> Dear spec experts,<br>
> <br>
> Happy New Year to you all! We thought this was a good time to share you some of<br>
> the thinking regarding Amber features for 2026.<br>
> <br>
> Currently we have one feature in preview - Primitive Patterns. We’d love to get<br>
> more feedback on this feature - please keep kicking the tires!<br>
> <br>
> We plan two new features in the near term. Draft JEPs are being worked on and<br>
> will be released as soon as possible. But here are some brief details while you<br>
> are waiting for the draft JEPs (in the name of efficiency, *please* let's save<br>
> discussion for that point).<br>
> <br>
> ## PATTERN ASSIGNMENT<br>
> <br>
> Pattern matching is an inherently partial process: a value either matches a<br>
> pattern, or it does not. But sometimes, we know that the pattern will always<br>
> match; and we are using the pattern matching process as a convenient means to<br>
> disassemble a value, for example:<br>
> <br>
> record ColorPoint(int x, int y, RGB color) {}<br>
> <br>
> void somethingImportant(ColorPoint cp) {<br>
> if (cp instanceof ColorPoint(var x, var y, var c)) {<br>
> // important code<br>
> }<br>
> }<br>
> <br>
> The use of pattern matching is great, but the fact that we have to use it in a<br>
> conditional statement is annoying. It’s clutter, and worse, it is making<br>
> something known by the developer and compiler look as if it were unknown; and,<br>
> as a consequence, the important code ends up being indented and the scope of<br>
> the pattern variables is limited to the then block. The indent-adverse<br>
> developer may reach for the following, but it’s hardly better:<br>
> <br>
> void somethingImportant(ColorPoint cp) {<br>
> if (!(cp instanceof ColorPoint(var x, var y, var c))) {<br>
> return;<br>
> }<br>
> // important code<br>
> }<br>
> <br>
> The real issue here is that both the developer and the compiler can see that the<br>
> pattern matching is not partial - it will always succeed - but we have no way<br>
> of recording this semantic information.<br>
> <br>
> What we really want is a form of assignment where the left-hand-side is not a<br>
> variable but a **pattern**. So, we can rewrite our method as follows:<br>
> <br>
> void somethingImportant(ColorPoint cp) {<br>
> ColorPoint(var x, var y, var c) = cp; // Pattern Assignment!<br>
> // important code<br>
> }<br>
> <br>
> Luckily, the spec already defines what it means for a pattern to be<br>
> unconditional (JLS 14.30.3), so we can build on this<br>
> <br>
> void hopeful(Object o) {<br>
> ColorPoint(var x, var y, var c) = o; // Compile-time error!<br>
> }<br>
> <br>
> <br>
<br>
Doing the advent of code of last December, I miss that feature :)<br>
<br>
But I'm still ambivalent about that feature, for me, it looks like we are missing the big picture.<br>
<br>
<br>
Every time i've talked about this feature in JUGs, one of the questions was why do we need to indicate the type given that the compiler knows it.<br>
For example<br>
<br>
void hopeful(ColorPoint cp) {<br>
(var x, var y, var c) = cp;<br>
<br>
// instead of<br>
<br>
ColorPoint(var x, var y, var c) = cp;<br>
}<br>
<br>
<br>
I wonder if the general question hidden behind is why is it a pattern assignment and not a de-structuration like in other languages.<br>
<br>
Let's take another example, in other languages, one can write swap like this<br>
int a = ...<br>
int b = ...<br>
(b, a) = (a, b);<br>
<br>
The equivalent would be<br>
<br>
record Pair(int first, int second) {}<br>
int a = ...<br>
int b = ...<br>
Pair(var x, var y) = new Pair(a, b);<br>
a = x;<br>
b = y;<br>
<br>
Or should we support assignment without the creation of new bindings ?<br>
<br>
record Pair(int first, int second) {}<br>
int a = ...<br>
int b = ...<br>
Pair(b, a) = new Pair(a, b);<br>
<br>
Or maybe, this feature should be named pattern declaration and not pattern assignment ?<br>
<br>
<br>
For me, this feature is about de-structuring assignment but by seeing through the keyhole of patterns, i'm fearing we are missing the big picture here.<br>
<br>
regards,<br>
Rémi<br>
</blockquote></div></div></div>