Amber features 2026

[Brian Goetz]

>
> 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.