Overload resolution simplification

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Thu Aug 15 02:30:23 PDT 2013


Hi,
This [1] is another post from Eric.

[1]
http://ericlippert.com/2012/10/02/how-do-we-ensure-that-method-type-inference-terminates/


On Thu, Aug 15, 2013 at 4:12 AM, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>wrote:

> Hi,
>
> On Thu, Aug 15, 2013 at 1:59 AM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> On 14/08/13 19:57, Ali Ebrahimi wrote:
>>
>>> Hi,
>>> please reread Eric's last two paragraph again[1]:
>>>
>> I think I read it well - I just believe Eric is talking about two
>> different  kinds of information flow:
>>
>> 1) return type constraints on methods cannot influence overload
>> resolution [as in Java]
>>
>> 2) lambda return value constraints CAN influence overload resolution [as
>> in Java]
>>
>
> 3) lambda return value constraints CAN also influence type inference (as
> in C#, based on my understandings from C#'s Spec & Eric's blog)
>
>
>>
>> The big question mark is: how do I get to a lambda return value
>> constraint? Well, you have to be able to check the lambda first; and when
>> can you do that?
>
>
> when you don't turn off type inference.
>
>
>> When you have a grip on the _instantiated_ lambda parameter types. This,
>> I believe, means that in certain cases, restriction (1) will play an
>> important factor, as certain lambdas will not be checked (or will be
>> checked with sub-optimal parameter types?) and you won't get what you
>> expect. More or less what you get with Comparator.comparing.
>>
>>
> Regards,
> Ali Ebrahimi
>


More information about the lambda-spec-observers mailing list