Generic type inference failure with callbacks in 1.4

[Nemo157]

interface Opts { url: string; }

declare function doit(url: string): number;
declare function doit(opts: Opts): boolean;

declare function call<T, U>(fn: (arg: T) => U, arg: T): U;

var n: number = call(doit, 'here');
var b: boolean = call(doit, { url: 'here' });

In 1.4.1.0 this snippet errors out with

test.ts(8,17): error TS2453: The type argument for type parameter 'T' cannot be inferred from the usage. Consider specifying the type arguments explicitly.
  Type argument candidate 'Opts' is not a valid type argument because it is not a supertype of candidate 'string'.

changing line 8 to ... = call<string, number>(doit, 'here'); successfully compiles as expected.

While playing around with this I noticed that while 1.3.0.0 would allow the call(doit, 'here') invocation it was still choosing the second overload of doit resulting in a return type of boolean and causing a compile error on the assignment. I'm glad 1.4.1.0 is now catching this error case, but it seems like inference of the type parameters should be entirely possible here.

[JsonFreeman]

The issue here was introduced in 1.1. This was because of a change in design with overload resolution.

When we do type argument inference, we have to relate the single signature of fn to the two overloads of doit. In 1.0, we would do this by inferring from both overloads. We would then add string and Opts as candidates, which would produce an error in both calls. This sounds like incorrect behavior.

However, the new behavior is also incorrect. Now, when we infer from two signatures (doit) to one signature (fn), we only infer from the last overload of doit. This causes us to infer Opts in both calls, although in the first call, we also infer string from the second argument, hence the error.

Ideally, we would want the second argument arg to inform our choice of overload. This would involve introducing something akin to contextual signature instantiation when inferring type arguments between groups of signatures. I'd want @ahejlsberg to weigh in as well.

[JsonFreeman]

This is basically the same problem as #248

[RyanCavanaugh]

I think we've effectively given up on handling overloads in inference