Overload resolution simplification

[Zhong Yu]

About the example from Eric's blog

    int M(Func<int, int> f){ /* whatever ... */ }
    string M(Func<string, string> f){ /* whatever ... */ }

    M(x=>x.ToUpper());

I think the main objection from EG is that this code is too brittle.
And it's not so much of a burden for javac to speculate the type of
`x`, it's about the burden on human readers to perform the same
detective work. So EG *chooses* not to compile it. I fully support
that decision.

However, if the type of `x` is perfectly knowable, e.g.
    m(Func<X,A>)
    m(Func<X,B>)
    m( x->expr );
it is a terrible waste to discard that knowledge, then require
programmer to supply the type information again. That is done for the
name of consistency and simplicity from a certain perspective; but
it'll only appear inexplicably silly to programmers.

Zhong Yu



On Wed, Aug 14, 2013 at 1:57 PM, Ali Ebrahimi
<ali.ebrahimi1781 at gmail.com> wrote:
> 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
>>