The deconstruction pattern is a special case of type pattern
No, it isn't. I think you want it to be, but it isn't.
, both starts by doing a typecheck (an instanceof), what is different
is how they bind variables after the typecheck.
So having the type inference on the type used by the typecheck working
for the type pattern but not for the destruction pattern strike me as
weird.
I think you may just not understand the model here.
In generality, a pattern:
- Is either total or partial. Deconstruction patterns are total;
other patterns we'll be able to express later, such as `Optional.of(var
x)`, are partial.
- Has a target type. In order for the pattern to match, the dynamic
type of the target must be cast-convertible to this target type.
- Has a set of output bindings.
So, if the user says:
case Foo(int x):
This means:
- (static) perform overload selection on the deconstructors of Foo,
and look for one that is compatible with the binding list `(int x)`.
Compile error if there isn't one (or are too many.)
- (dynamic) test the target to see if it is cast-convertible to Foo.
If it is, because the pattern is total (no additional match conditions),
the deconstruction pattern is going to match. Invoke the deconstructor
to get the bindings.
At the same time, i understand why people can find the syntax awkward.
I just want to be sure that it's not awkward just because it's a new
syntax.
It's not the syntax, it's the concept.
By example, with this switch, that has two cases that are semantically
identical
switch(point) {
case Point p where p.x() == 0 -> ...
case Point(var x, var _) where x == 0 -> ...
No, they are not semantically identical, except maybe for a record
(because records are so constrained.) The first is invoking a method
p.x(); the second is invoking a deconstructor, which has a binding
called x. If the two happen to be talking about the same x, then it
will come out the same, but you have no reason to assume that just based
on the spelling of `x`. They could be describing entirely different
things. The language has no business guessing the semantics of a method
based on its name.
In order to make them work out, you need a system of "properties" to
guarantee that when a deconstructor binds a `x`, and an accessor method
returns an `x`, they are guaranteed to be the same `x`. I don't blame
you for wanting such a system, but you don't get to sneak it in the back
door....
How the deconstructors are represented in the surface language, how
they are called or how the data values flow to the bindings are
another stories for another time.
No, this is not a syntax problem; it is a conceptual problem. You are
asserting that deconstructors means something different than they do.
