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, or worse
Foo() = f
looks like, well, who knows.
- 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.
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
