Deconstruction but no destructuring when declaring local variables

forax at forax at
Tue Apr 7 18:50:37 UTC 2020

> De: "Brian Goetz" <brian.goetz at>
> À: "Remi Forax" <forax at>, "amber-spec-experts"
> <amber-spec-experts at>
> Envoyé: Mardi 7 Avril 2020 20:29:52
> Objet: Re: Deconstruction but no destructuring when declaring local variables

> I'd like to take this up later, but let me read into the record a few points
> we've already discussed on this matter:

> - Yes, it is very tempting to like this syntax because in the degenerate case,
> where `Foo f` is a type pattern, it looks just like a declaration with an
> initializer, so much so that we can say "aha, you never knew Java had patterns
> from day 1!". But, ultimately this runs out of gas when patterns get more
> complicated, so be wary of being seduced by how natural it looks in the
> simplest case.

> Even the middle ground:

> Point(var x, var y) = p

> doesn't look much like a declaration,
I don't know, it's maybe familiarity. It's weird the first time you see it, but it''s close the kind of deconstructing you have in JavaScript or C# 

> or worse

> Foo() = f

> looks like, well, who knows.
x instanceof Foo() looks as weird for me. 
We should not allow deconstruction pattern that doesn't introduce at least a variable, in instanceof and in this case. 

> - This really only works when the pattern is _total_ on the target type, so that
> the pattern provably applies (modulo null.) That can work for record
> deconstruction patterns but not always for other pattern types. Alternately, we
> can have a statement form "bind P = target else { ... }" for partial patterns,
> but then we lose the nice connection noted above with declarations.
Yes, for both local variable declarations and instanceof, the pattern has to be total, that a major difference with switch. 
I don't think it's wise to allow by example constants with an instanceof 
x instanceof Point(var x, 11) 

at the same time, if you allow local variables in patterns, you have a nice way to write equals 
class A { 
int foo; 
int bar; 

public boolean equals(Object o) { 
return o instanceof A(,; 

which can be simplified to 
public boolean equals(Object o) { 
return o instanceof A(foo, bar); 

but it's a step roo far IMO. 


> On 4/7/2020 2:20 PM, Remi Forax wrote:

>> There was discussions about the danger of only providing instanceof + the
>> deconstruction pattern and not a way to have the same kind of destructuring
>> when declaring local variables

>> By example, instead of
>>   Point p = ...
>>   int x = p.x();
>>   int y = p.y();

>> one can write
>>   Point p = ...
>>   if (!(p instanceof Point(int x, int y)));

>> I think we should restart those discussions because variables declarations is
>> like a third places where patterns can appear (instanceof and switch being the
>> other two).

>> I don't really want to propose a syntax, so the next examples will be to give an
>> idea of the semantics
>> The idea is to allow patterns on the left side of an '='.
>> So
>>   pattern = value;

>> We already have
>>   Point p2 = p;  // the type pattern

>> so if we expand it with the new patterns proposed for instanceof, we get
>>   Point(int x, int y) = p;   // the deconstruction pattern with explicit type
>> and
>>   Point(var x, var y) = p;   // the deconstruction pattern with var

>> regards,
>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list