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