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

[Igorbek]

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.

[kitsonk]

If you say a generic without any constraints, like <T> then anything can be assigned to it, therefore the first overload pattern is ignored and the second one is selected. In the first example, to compare apples to apples you would be better to write:

declare function f(a: Promise<any>): number;
declare function f(a: any): string;

[Igorbek]

Why is first overload ignored? If T can accept anything, including Promise<X> that means, in run time, the first overload would also possibly be selected.

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

const g = <T>(a: T) => f(a); // g is a simple proxy to f

declare const p: Promise<number>;

f(p); // first overload, number in compile-time, number in run-time
g(p); // g uses second overload of f in compile-time, so the result is of type string in compile-time
 // in fact, it is number in run-time

[kitsonk]

What is f2 and g doesn't have any overloads. Your code isn't matching what you are trying to explain.

[Igorbek]

@kitsonk sorry, it was a typo. I've updated the sample code and added more explanation.

[DanielRosenwasser]

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.

Here you go! #1805.

[DanielRosenwasser]

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

[Igorbek]

@DanielRosenwasser that would be great. I've walked through referenced #1805, and it seemed to only cover mostly case 1, and completely missing case 2 where you cannot really control function application.
When case 1 is just unfortunate, case 2 is really a source of compile-time and run-time inconsistency.

[simonbuchan]

Current real world example: the current typings for react mean that React.createElement() cannot take a ReactType = keyof JSX.IntrinsicElements | ComponentType or ComponentType<P = any> = StatelessComponent<P> | ComponentClass<P>, even though it can take keyof JSX.IntrinsicElements or StatelessComponent<P> or ComponentClass<P>. This is pretty confusing!

[Igorbek]

@tycho01 pointed that the issue was identified before in #12424 (comment) by @jcalz when discussing #6606

[simonbuchan]

That is delaying overload resolution until generic parameters are bound, this is synthesizing a union of possible result types when overload resolution would otherwise fail, they don't seem that similar?

[simonbuchan]

Oh, reread OP, maybe it's worth opening what I thought it was as a new issue?