[External] : Re: Looking ahead: pattern assignment

[Brian Goetz]

>     Minimally, we have to align the semantics of local variable
>     declaration with assignment with that of pattern matching; `T t =
>     e` should have the same semantics whether we view it as a local
>     declaration plus assignment, or a pattern match. This means that
>     we have to, minimally, align the assignment-context conversions in
>     JLS 5.  (If we wish to support patterns in method/lambda formals,
>     we also have to align the method-invocation context conversions.)
>
>
> More questions,
> About the conversions, you means the conversions with the top-level 
> type of the pattern, or conversions with the sub-patterns too ?

What I mean is that if I have a method

      void m(Integer x) { }

and I call m(1), then today we do an boxing conversion because boxing is 
one of the conversions we do in method invocation context.  If we want 
to interpret this as a pattern match, we should get the same answer, 
which means we need to define what conversions we apply to the parameter 
when the parameter pattern has a certain target type, and that has to 
align with existing invocation context conversions.

> For lambda formals, there is a syntax question, do we support a syntax 
> without parenthesis if there are only one argument ?
>   Point(var x, var y) -> ...

No for now; ask me again in two years ;)

> For methods and lambda formals, does the top-level pattern as to have 
> a binding ?
> Like in your examples
>   void m(Point(var x, var y) p) { ... }
> or can we avoid it
>   void m(Point(var x, var y)) { ... }

Today, yes, because method parameters need names.  Tomorrow, when we 
allow method parameters to be elided via _, we might consider allowing 
omitting the parameter binding, but we might also just require it to be _.

> For classical assignment, enhanced for loop, try-with-resources and 
> lambda formals we can have inference, do we have inference with patterns ?
>   - assignment
>     (var x, var y) = aPoint;

That's not a pattern :)

     Point(var x, var y) = aPoint

is a pattern.  In this case, we can infer what type x and y have based 
on the declaration of the selected deconstructor.

>   - enhanced loop
>     for((var x, var y) : aListOfPoints) { ... }
>   - try-with-resources
>     try((var x, var y): aClosablePoint) { ... }
>   - lambdas formals
>     Consumer<Point> consumer = ((var x, var y)) -> ...

Same "not a pattern" comment.

> Also should we support the parenthesized pattern and the AND pattern 
> in those contexts ?

The key criteria is totality.  In practicality that means unguarded type 
and deconstruction patterns.