Overload resolution simplification

[Ali Ebrahimi]

Hi,
please reread Eric's last two paragraph again[1]:

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