> On Mar 27, 2023, at 8:19 AM, Brian Goetz <[email protected]> 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.
