Fwd: Overload resolution simplification

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Aug 14 14:47:52 PDT 2013

On 14/08/13 22:44, Zhong Yu wrote:
> We shouldn't treat them as equals. Why don't we first use non-lambda
> args to do some inference on the methods, and prune some overload
> candidates, before moving on to resolve the lambda args. This will
> solve the above problem. It'll also solve the problem of
>      Comparator<String> comparator = Comparator.comparing(s->s.length());
That's exactly what happens - we've been supporting what we call 
out-of-order method checking for quite some time; it's not like we are 
missing anything obvious - sorry.

Again you seem to keep ignoring the fact that we can't use 
Comparator<String> during overload resolution. Which means there would 
not be such thing as T = String, which again means that, during 
overload, we cannot type-check the lambda body (as we don't know what 
the parameter type is) and therefore cannot use the lambda body to 
disambiguate between the multiple overloads.


More information about the lambda-spec-observers mailing list