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.
