Fwd: Overload resolution simplification

[Zhong Yu]

On Wed, Aug 14, 2013 at 4:47 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> 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

On top of the thread Dan described the case as "we never could
disambiguate in the first place".

> 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

I guess what I'm supporting is resolving the type of the implicit
lambda before overload resolution, which you guys are abandoning.

> 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