[External] : Re: Looking ahead: pattern assignment

[Remi Forax]

De: "Brian Goetz" <brian.goetz at oracle.com> 
À: "Remi Forax" <forax at univ-mlv.fr> 
Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net> 
Envoyé: Samedi 13 Mars 2021 02:41:58 
Objet: Re: [External] : Re: Looking ahead: pattern assignment 




BQ_BEGIN


BQ_BEGIN


BQ_BEGIN
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.) 
BQ_END


More questions, 
About the conversions, you means the conversions with the top-level type of the pattern, or conversions with the sub-patterns too ? 

BQ_END

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


What is not clear to me is are you proposing those conversion to be applied on the target type of the pattern or even on the target type of the sub patterns. 

But perhaps it's a more general question for the deconstruction pattern, if we do not use 'var' 
case Point(Type1 x, Type2 y): ... 
what are the possible types for Type1 and Type2 given that Point is declared as Point(DeclaredType1 x, DeclaredType2 y). 
Do Type1 has to be DeclaredType1 (resp. Type2 == DeclaredType2) or do some conversions are allowed ? 


BQ_BEGIN



BQ_BEGIN

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

BQ_END

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


BQ_BEGIN

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)) { ... } 

BQ_END

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

Given that you can get the parameter names by reflection, requiring '_' may not be a bad idea. 
This lead to another question, should we consider using a Pattern declared inside a method declaration only as syntactic sugar or should the notation reflected in an attribute of the method accessible by reflection ? 


BQ_BEGIN



BQ_BEGIN

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; 

BQ_END

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

It's an alternative syntax to the deconstruction pattern, usual deconstruction pattern is 
Type(pattern1, pattern2, ...) 
The alternative syntax is 
(pattern1, pattern2, ...) 
and the type is found by type inference. 

This may be important to explore that now because the syntax may clash with the parenthesized pattern because 
(pattern) 
can be seen as both. 


BQ_BEGIN



BQ_BEGIN

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

BQ_END

Same "not a pattern" comment. 


BQ_BEGIN

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

BQ_END

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

And the pattern method if we allow some pattern methods to be declared as total. 

Rémi