Allow calls to overloaded functions when all possible combinations of union type parameters resolve to valid overloads

TypeScript Version: 2.4.1

Code

Case 1

// overloaded functions
declare function f(a: number): number;
declare function f(a: string): string;

function g<T extends number | string>(a: T) {
    return f(a); // either of arguments is acceptable
//           ~
// Argument of type 'T' is not assignable to parameter of type 'string'.
//  Type 'string | number' is not assignable to type 'string'.
//    Type 'number' is not assignable to type 'string'.
}

Case 2

declare function f2<T>(a: Promise<T>): number;
declare function f2<T>(a: T): string;

function g2<T>(a: T) {
    const result: string = f2(a); // first overload is ignored, but the argument can be a Promise
    return result;
}

Expected behavior:

Case 1: compiles with no errors Case 2: error that type string | number is not assignable to type string

Actual behavior:

Case 1: error

Argument of type 'T' is not assignable to parameter of type 'string'.
  Type 'string | number' is not assignable to type 'string'.
    Type 'number' is not assignable to type 'string'

Case 2: compiles without errors

Note

I remember here were some discussions about that, so that verifying all possible paths may result in N*M complexity (N overloads, M constituent types in unions). I could not find it.

The second case seems unsafe at all, because skips a possibly valid overload which may effect on return type. I expect that f2(a) would be of type number | string because either of these two overloads can play. It actually has the same result with a: any.

[DanielRosenwasser]

I was talking to @ahejlsberg about something like this a few days ago. Maybe we can bring it up again.

[KiaraGrouwstra]

I think delaying the resolution is basically the same as propagating the overload.

Oh, my interpretation had been that propagating the overload would mean storing the different possible outcomes, which may sound manageable in this toy example, but perhaps less so if we’d be nesting calls with respectively n, i, j overloads, making for n * i * j potential overloads throughout the evaluation from the top level.

I’m thinking we might not necessarily need much more complexity. Knowing:

• we just passed RegExp to v
• inferring from this that T would be RegExp as well

… then if rather than <T>(v: T) => Match(T) we’d be evaluating the return type of signature <T>(v: T extends RegExp) => Match(T) instead, I’m thinking that might already suffice to evaluate to Match(RegExp) -> 0.