Overload resolution simplification

[Ali Ebrahimi]

Hi,


On Fri, Aug 16, 2013 at 3:44 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  On 15/08/13 23:54, Ali Ebrahimi wrote:
>
>  For overloaded methods we act in multiple phases.
>> phase1: we do type check lambda without boxing, unboxing and widening in
>> return type.
>>  if we get only one overload that successfully type checks lambda So
>> inference has been succeed, otherwise go phase 2.
>>
>> phase2: we do type check lambda without boxing and unboxing but with
>> widening in return type. if we get only one overload that successfully type
>> checks lambda So inference has been succeed, otherwise go phase 3.
>>
>> phase3: we do type check lambda with boxing, unboxing and widening in
>> return type. if we get only one overload that successfully type checks
>> lambda So inference has been succeed, otherwise ERROR.
>>
>>  Do you plan to use information about i.e. assignment context when doing
>> steps 1/2 ?
>>
> yes, of course for inferring method's type args and finaly for lambda's
> input type args.
>
> If that's the case, see my reply to Zhong Yu, as I believe your proposed
> scheme has the same complexity shown there. Not to mention that your scheme
> also features a degree of brittleness that the EG unanimously rules out -
> i.e. any error in the lambda body can make the method become inapplicable -
> this means that seemingly refactorings of a method in some API might
> trigger change in overload selection of methods that receive a lambda
> calling that API - ouch!
>

I think this can also happen in non-lambda world.
Can you show some example that how this may happen for comparing?


Ali Ebrahimi