Is case var(var x, var y) a valid syntax ?

[Brian Goetz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200907/53aeec14/attachment.htm>