Amber features 2026

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Gavin Bierman" <gavin.bierman at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 14, 2026 9:47:15 PM
> Subject: Re: Amber features 2026

>>
>> If we rewind a bit, for a case inside a switch, it makes sense to creates new
>> bindings ...
>>
>> For an instanceof, again we want bindings ...
>>
>> Now for an assignment, this is far less clear for me, that we do not want users
>> to be able to choose if they want fresh new local variables or reuse existing
>> ones (i do not think that mixing both should be supported).
> 
> I think you are over-indexing on the shorthand name given to this feature.
> 
> When we write
> 
>     String s = f()
> 
> we colloquially think of this as "assignment", but technically the name
> of this is "local variable declaration with initializer" (LVDI).
> 
> And, look closely at this LVDI usage: is it _really_ a LVDI, or is it a
> type pattern being unconditionally matched to the expression `f()`?  The
> answer is: IT DOESN'T MATTER!  The two have exactly the same semantics.
> This is not an accident; exhaustive patterns are a strict generalization
> of LVDI.  (There are some minor corner cases that can be addressed with
> small cleanups in JLS Ch5.)
> 
> We could find a more accurate name than "Pattern Assignment", but my
> worry is that this would obfuscate the very real similarity between LVDI
> and pattern assignment.
> 
> And we have definitely discussed and ruled out "use any old mutable
> variable as a nested pattern", and I don't see any reason to reopen that
> question just because the word "assignment" is being used here.
> 
>> By piggybacking on patterns, we are restricting ourselves to think in terms of
>> patterns and not more broadly in terms of de-structuring/multiple assignments.
> 
> I think you have this backwards.  Patterns, specifically
> record/deconstruction patterns, _are_ Java's notion of destructuring.
> Just as records are our tuples, and functional interfaces are our
> function types.  Just as we are not adding tuples or structural function
> types, it would be a self-inflicted wound to add some sort of
> destructuring that does not run through pattern matching.
> 
>> Asking the question differently, apart from the fact that that this feature has
>> a name that starts with "pattern",
>> do you think that re-assigning local variables is something that should be
>> considered for this feature ?
> 
> I have two answers to that question.
> 
> 1.  It makes no sense to think of this as part of _this feature_,
> because this feature is built on pattern matching.  If you want that,
> then you are asking for it as part of pattern matching in general, where
> you can turn a mutable variable into a pattern somehow.
> 
> 2.  I think we very much *do not want* pattern matching to be able to
> mutate existing variables, for multiple reasons.  This was already well
> covered the first time around.
> 
> Short answer; absolutely not.


Let's try from the other direction, what will make this feature a pain to use if we do not allow to mutate existing variables.

So what are the cases in Java where people will want to mutate local variables.

- you mutate variables when you reduce accumulators in a loop
  var v1 = ...
  var v2 = ...
  for(...) {
    (v1, v2) = f(v1, v2);
  }

- you mutate variables after a condition
  var v1 = ...
  var v2 = ...
  if (...) {
    (v1, v2) = f(...);
  }

- you mutate variables when you transfer values in between scopes
  Type1 v1;
  Type2 v2;
  try(...) {
    (v1, v2) = f(...);
  }
  
in all those cases we already know that using pattern assignment will be painful.

And the reason of this pain is that this feature is called "pattern assignment" so obviously, because it's a pattern, it can not mutate existing local variables.

We are boxing ourselves in a corner by calling this feature pattern assignment,
yes, it should use the destructuring part of an exhaustive pattern, but it's not a pattern.

regards,
Rémi