[External] : Re: Looking ahead: pattern assignment
Brian Goetz
brian.goetz at oracle.com
Sun Mar 14 12:59:10 UTC 2021
> 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.
>
>
> 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.
The sub-patterns don't enter into it. Because a pattern in this context
must be total on the type of the parameter/assignee, if it is a pattern
with sub-patterns, they must be total too, otherwise the whole thing is
not total.
If I have
Point(var x && x == 0, var y) = aPoint
I'm going to get an error that says that the pattern on the LHS is not
total on the target type of the thing on the RHS, which is Point.
> 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 ?
Go back to the previous point: the pattern must be total, so
deconstructor sub-patterns must be total on the type of the
deconstructor bindings.
I think you're asking something like: if we have deconstructor `Foo(int
x)`, can I invoke it with `Foo(Integer x)`? In other words, is there a
set of _pattern conversions_ where we are willing to make up the
difference between two similar-enough patterns, and call it total? I
have resisted this so far, because I think there are ample other ways to
get to what you want without the complexity of JLS Ch5. But I'll make a
note to come back with a more detailed explanation of the problem here.
> 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 ?
Definitely sugar. Suppose we have a pattern P with target type T:
void m(P x) {
M
}
is equivalent to
void m(T x) {
P = x;
M
}
That said, its possible that _Javadoc_ might want to do more. Since
total patterns can still have remainder, its reasonable for the Javadoc
to capture this. But reflection is about what's in the classfile, not
the language model, so this is 100% not reflection's business.
>
> 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.
OK, as long as we're clear that this "alternate syntax" just in your
head. (See also: https://en.wikipedia.org/wiki/Alternative_facts).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210314/b02b4ea9/attachment.htm>
More information about the amber-spec-experts
mailing list