[External] : Re: Looking ahead: pattern assignment

[Brian Goetz]

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