Overload resolution simplification

[Maurizio Cimadamore]

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]

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 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.

Maurizio
>
> "Notice that type information does flow both ways for lambdas! If you say
> N(x=>x.Length) then sure enough, we consider all the possible overloads of
> N that have function or expression types in their arguments and try out all
> the possible types for x. And sure enough, there are situations in which
> you can easily make the compiler try out billions of possible
> combinations<http://blogs.msdn.com/b/ericlippert/archive/2007/03/26/lambda-expressions-vs-anonymous-methods-part-four.aspx>to
> find the unique combination that works. The type inference rules that
> make it possible to do that for generic methods are exceedingly complex and
> make even Jon Skeet nervous. This feature makes overload resolution
> NP-HARD<http://blogs.msdn.com/b/ericlippert/archive/2007/03/28/lambda-expressions-vs-anonymous-methods-part-five.aspx>.
>
>
> Getting type information to flow both ways for lambdas so that generic
> overload resolution works correctly and efficiently took me about a year.
> It is such a complex feature that we only wanted to take it on if we
> absolutely positively would have an amazing return on that investment.
> Making LINQ work was worth it. But there is no corresponding feature like
> LINQ that justifies the immense expense of making this work in general."
>
>
> Regards,
>
> Ali Ebrahimi
>
> [1]-
> http://stackoverflow.com/questions/3203643/generic-methods-in-net-cannot-have-their-return-types-inferred-why
>
>
> On Wed, Aug 14, 2013 at 2:59 PM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> On 14/08/13 10:57, Maurizio Cimadamore wrote:
>>
>>> but it would seems that C# can use the target-type information _ahead_ of
>>> overload resolution to perform inference, thus being able to reject
>>> applicable candidates based on return mismatch (which Java cannot do).
>>>
>> This is incorrect - I found this [1] which clearly states (Eric Lippert)
>> that by design, in C# type information flows from argument types outwards,
>> not the other way around. This means that several examples discussed in
>> this mailing list wouldn't work in C# too, especially the ones around
>> Comparator.comparing - in that case in fact, the only way to type-check the
>> lambda is to instantiate the formal parameter of the method with the
>> information that's available from the target-type context. Java won't do it
>> because that would break the invariant that overload selection should not
>> depend on target type. It seems like C# has a similar (sensible)
>> restriction.
>>
>> [1] - http://stackoverflow.com/**questions/3203643/generic-**
>> methods-in-net-cannot-have-**their-return-types-inferred-**why<http://stackoverflow.com/questions/3203643/generic-methods-in-net-cannot-have-their-return-types-inferred-why>
>>
>> Maurizio
>>