[Errors] Type argument inference from signatures infers fewer candidates

[mhegazy]

interface Promise<T> {
then<U>(success?: (value: T) => U, error?: (error: any) => U, progress?: (progress: any) => void): Promise<U>;
done<U>(success?: (value: T) => any, error?: (error: any) => any, progress?: (progress: any) => void): void;
}

interface IPromise<T> {
then<U>(success?: (value: T) => IPromise<U>, error?: (error: any) => IPromise<U>, progress?: (progress: any) => void): IPromise<U>;
then<U>(success?: (value: T) => IPromise<U>, error?: (error: any) => U, progress?: (progress: any) => void): IPromise<U>;
then<U>(success?: (value: T) => U, error?: (error: any) => IPromise<U>, progress?: (progress: any) => void): IPromise<U>;
then<U>(success?: (value: T) => U, error?: (error: any) => U, progress?: (progress: any) => void): IPromise<U>;
done? <U>(success?: (value: T) => any, error?: (error: any) => any, progress?: (progress: any) => void): void;
}

declare function testFunction11(x: number): IPromise<number>;
declare function testFunction11(x: string): IPromise<string>;
declare function testFunction11P(x: number): Promise<number>;
declare function testFunction11P(x: string): Promise<string>; 

var s11: Promise<number>;
var s11a = s11.then(testFunction11, testFunction11, testFunction11); // ok
var s11b = s11.then(testFunction11P, testFunction11P, testFunction11P); // ok
var s11c = s11.then(testFunction11P, testFunction11, testFunction11); // ok

Used to all succeed, but now they all fail. This is because when we collect candidates for U from testFunction11 and testFunction11P, we only use the last overload instead of all the overloads. This is an algorithmic change in the new compiler.

They used to all succeed, but they were Promise<{}>, which is not super meaningful anyway.

r11a has similar behavior in promisePermutations3.ts

[sophiajt]

Treating this like other performance improvements that may have an impact on real world code. Please ensure this does not impact known code before we make this change to the spec.

[JsonFreeman]

Keep in mind that this is also addressed by issue #248, which has a proposal for a third algorithm we are considering.

[JsonFreeman]

Closing because we have a new algorithm to try out (namely the one proposed in issue #248)

[JsonFreeman]

Anders, please change the spection 3.8.6 to reflect the new design (that is until we try the new proposal).