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>, "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 14, 2026 9:05:04 PM
> Subject: Re: Amber features 2026

>> But I'm still ambivalent about that feature, for me, it looks like we are
>> missing the big picture.
>>
>>
>> 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.
> 
> Except that this is not big picture; it's more like code-golf.
> 
> Yes, the part of people's brains that, when shown a new feature, they
> will try to squeeze out tokens that they do not see as essential, works
> in permanent overdrive, so OF COURSE people will ask this.  But this is
> surface, not substance; the substance is that "exhaustive pattern" is a
> thing, and it behaves very very similiarly to existing rules about
> assignment.
> 
> There are future ideas in the pipeline that might be layered on and
> reduce the ceremony of this and other things, but we're going to leave
> that for another day.

Agree on the fact that exhaustive pattern is a thing.

If we rewind a bit, for a case inside a switch, it makes sense to creates new bindings because re-using local variables does not make a lot of sense, we want people to use the fact that a switch can yield a value for sending values between the switch and the rest of the program.

For an instanceof, again we want bindings so there is no need to write a cast just after the instanceof.

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

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 wonder if the general question hidden behind is why is it a pattern assignment
>> and not a de-structuration like in other languages.
> Because Java does not have destructuring, because it does not have
> structural types.  It has records (nominal types) and record patterns
> (and eventually carriers and deconstruction patterns for them), but
> patterns are a step removed from destructuring.
> 
>> Or maybe, this feature should be named pattern declaration and not pattern
>> assignment ?
> 
> The key aspect here is that we have a pattern that is known to be
> exhaustive, from which we want to extract (assign) multiple bindings
> unconditionally.  Currently, such a pattern would have to use a
> conditional construct, which (a) requires you use conditionality to deal
> with something unconditional, and (b) prevents the compiler from doing
> better type checking.  When a pattern is exhaustive, it behaves _just
> like local variable declaration with initialization_, which operates by
> assignment.  You can think of "pattern assignment" as a shorthand for
> for that.

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 ?

regards,
Rémi