Fwd: Overload resolution simplification

[Maurizio Cimadamore]

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.

Maurizio