Record pattern inference & capture

[Dan Smith]

> On Mar 27, 2023, at 8:19 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Not directly related, but something to keep in mind - when we get to full deconstruction patterns, we will also have to do some overload selection here, because the type named in the pattern may have multiple deconstructors.

Sure, although I'm skeptical of attempts to mirror method invocation overload resolution here. The intuitions about invocation compatibility (as used by method invocations) don't carry over very when you switch to cast compatibility (as used by patterns).

> OK, on to your point.  You've got a match candidate that is something like Function<String,String>, and a pattern like 
> 
>     case UnaryOperator(...)
> 
> on it.  (I assume the use of functional interfaces is merely incidental here, and you're just trying to infer the type arguments of the pattern UnaryOperator<T> from a match target of Function<U,V>.)

Yep, just some well-known types that have interesting properties in their use of generics.

> Mapper<T> extends Function<T,T>, so really you are asking whether there is a solution for T <: CharSequence and T :> String, because if there is no solution, we should reject the pattern as not applicable, right?

Right. And further, if there is a solution, what is the parameterization? The answer will be a wildcard with certain bounds, as determined by bounds on an inference variable.