Overload resolution simplification
ali.ebrahimi1781 at gmail.com
Thu Aug 15 16:36:15 PDT 2013
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?
More information about the lambda-spec-observers