De: "Brian Goetz" <brian.go...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>
Cc: "amber-spec-experts" <amber-spec-experts@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
