Inconsistent type inference on overloaded function types

[jsalvata]

🔎 Search Terms

type inference of overloaded functions

🕗 Version & Regression Information

The behaviour seemed to change between 4.0.5 and 4.1.5, but it was incorrect nonetheless.

⏯ Playground Link

https://www.typescriptlang.org/play?ts=4.0.5#code/C4TwDgpgBAwghgGwQIzgYwNYB4BKA+KAXigAoAnCAZwFcFgAuKHASiIIDcB7ASwBMBuALAAoUJCgB5MMG6cAdpSJQA3lDTzgEAB4MocOSCgBfIcJHawnMsChjoAQUog5aAGLUXM+VntRtmuV5FDww5TgB3OQBtAF0AGkk-HQhAxSkvBQT8JWURKCgAegKoAGVwuDBbAAsqaGBwzigEbjkqW0bKCDqaqAAzDzzSADoRuDIAc0pGKJGh+wT4JFRMXDwY5kYuPlN8klmxyenZ+ckFxBR0bHx1zZ4BERMREX7PWTkoMDJOAFtuSm5eiAfEkAkEoCEwpFYgkJCCUmD0m9KFk8CReoxHM43B40BkfDCUaxlEYnsIXri3n0AIwkOSMOTUb7ICBkBJoRiLC4rBlMll4DZQLb3Mk4jLU2n0xnM1lQTiMRHyZFqDnnZbYHnS-m3bbPUWU3o0-YTKZ6AyxIkksyicAOJwuCRkABynGAWFcBGIrjhqSgmJc7le3havRZUAA+idg6GwxIElGyOHsgB+WxkajQRi9RCdUwiT4-P4AkBoqnMXPW8QAFSpSj9aAdztddk4vWpeFM6gUNmAVMY1aUwDTEFMQA

💻 Code

type Callback<R> = (result: R) => void;
type Options = { context: any };

export type AsyncFunction<A extends unknown[], O extends Options, R> = {
  // Swap these two lines to see the fun
  (...args: [...A, Callback<R>]): void;
  (...args: [...A, O, Callback<R>]): void;
};

function promisify<A extends unknown[], O extends Options, R>(f: AsyncFunction<A, O, R>) {}

function f1(n: number, c: Callback<number>): void;
function f1(n: number, o: Options, c: Callback<number>): void;
function f1(...args: any[]) {}

type AsyncOrNot<F> = F extends AsyncFunction<infer _A, infer _O, infer _R> ? true : false;

promisify(f1);

type T1 = AsyncOrNot<typeof f1>;
const t1: T1 = true;

🙁 Actual behavior

In version 4.0.5, either the inference in the function call or the inference in the conditional type succeeds, depending on the order in which the overloads are declared.
In all later versions up to and including 5.4.0 beta, the inference in the conditional type always fails.

🙂 Expected behavior

Type inference for the same type against the same generic type to always succeed or always fail, whether it is done for a generic function call or for evaluating the extends clause in a conditional type.

Additional information about the issue

No response

[rotu]

I think this might be a clearer example of part of this bug. Namely, while the function type extends both signatures, it can only infer the last return type.

type PolyFun = ((x:number)=>number) & ((x:string)=>string)

type A1 = PolyFun extends ((x:number)=>infer Z) ? Z : null // null, expected number
//   ^?
type A2 = PolyFun extends ((x:number)=>number) ? number : null // number
//   ^?

type A3 = PolyFun extends ((x:string)=>infer Z) ? Z : null // string
//   ^?
type A4 = PolyFun extends ((x:string)=>string) ? string : null // string
//   ^?

Workbench Repro

[typescript-bot]

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of this repro running against the nightly TypeScript.

---

Comment by @rotu

⚠️ Assertions:

• type A1 = null
• type A2 = number
• type A3 = string
• type A4 = string

Historical Information

Version	Reproduction Outputs
4.9.3, 5.0.2, 5.1.3, 5.2.2, 5.3.2	⚠️ Assertions: type A1 = null type A2 = number type A3 = string type A4 = string

[MajorLift]

Another simple repro focusing on the inconsistent behavior of typeof vs. infer/Parameters<T>/ReturnType<T> on overloaded functions.

/** overload signature 1 */
function overloadedFunction(
  stringArg: string,
): Record<typeof stringArg, string>;

/** overload signature 2 */
function overloadedFunction(
  numberArg: number,
): Record<typeof numberArg, number>;

/** implementation signature */
function overloadedFunction(
  arg: string | number,
): Record<string, string> | Record<number, number> {
    return {};
}

/**
 * `typeof` only displays the overload signatures and omits the implementation signature (this is expected behavior).
 * 
 * type TypeOfKeyword = {
 *   (stringArg: string): Record<typeof stringArg, string>;
 *   (numberArg: number): Record<typeof numberArg, number>;
 * }
 */
type TypeOfKeyword = typeof overloadedFunction;
//    ^?

/**
 * `infer`, `Parameters<T>`, `ReturnType<T>` only use the last overload signature (this is unexpected behavior).
 * If the order of the overload signatures is changed or new signatures are added, these results change as well.
 * 
 * type InferKeyword = {
 *   parameters: [numberArg: number];
 *   returnValue: Record<number, number>;
 * }
 */
type InferKeyword = typeof overloadedFunction extends (...args: infer P) => infer R 
//   ^?
    ? { parameters: P; returnValue: R; } 
    : never;
type ParametersUtility = Parameters<typeof overloadedFunction>; // [numberId: number]
//   ^?
type ReturnTypeUtility = ReturnType<typeof overloadedFunction>; // { [x: number]: number; }
//   ^?

Workbench repro

[MajorLift]

There's also the question of what InferKeyword in the above example should evaluate to.

Currently, it would probably be an expression of the implementation signature, even though only overload signatures are supposed to be externally exposed.

type InferKeyword = {
  parameters: [arg: string | number];
  returnValue: Record<string, string> | Record<number, number>;
}

Ideally, there should be a way to get an accurate discriminated union with the overload signatures as members.

type InferKeyword = {
  parameters: [stringArg: string];
  returnValue: Record<string, string>;
} | {
  parameters: [numberArg: number];
  returnValue: Record<number, number>;
}

To achieve this, we may need a new syntax for infer that lets it infer both the parameters and return value of a function type, or more generally has a distributive property over generic arguments. e.g.

type NewInferSyntax = typeof overloadedFunction extends infer ((...args: P) => R)
    ? { parameters: P; returnValue: R } 
    : never;

[typescript-bot]

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of this repro running against the nightly TypeScript.

---

Comment by @MajorLift

⚠️ Assertions:

• type TypeOfKeyword = { (stringArg: string): Record; (numberArg: number): Record; }
• type InferKeyword = { parameters: [numberArg: number]; returnValue: Record; }
• type ParametersUtility = [numberArg: number]
• type ReturnTypeUtility = { [x: number]: number; }

Historical Information

Version	Reproduction Outputs
5.0.2, 5.1.3, 5.2.2, 5.3.2	⚠️ Assertions: type TypeOfKeyword = { (stringArg: string): Record; (numberArg: number): Record; } type InferKeyword = { parameters: [numberArg: number]; returnValue: Record; } type ParametersUtility = [numberArg: number] type ReturnTypeUtility = { [x: number]: number; }
4.9.3	⚠️ Assertions: type TypeOfKeyword = { (stringArg: string): Record; (numberArg: number): Record; } type InferKeyword = { parameters: [numberArg: number]; returnValue: Record; } type ParametersUtility = [numberArg: number] type ReturnTypeUtility = { [x: number]: number; }

[LaysDragon]

Not sure if this is related, but I encounter the problem that pipe method isn't work well with overload function. It also depending on the order in which the overloads are declared.

declare function pipe<A, B>(a: A, ab: (a: A) => B): B;

function testFn(a: number): number;
function testFn(a: string): string;
function testFn(a: any): any {
  return a;
}

testFn(1); // its work
pipe(1, testFn); // Error: Argument of type 'number' is not assignable to parameter of type 'string'. ts(2345)
```,.

[no-stack-dub-sack]

Sharing another example that got me for a while today until I found this issue when I was about to open my own. I was astounded to find out that reversing the order of the fist and second overloads fixes the problem as I don't see anything in the TS documentation about the order of the overloads mattering with regards to type specificity:

export type KeyExtractor<T, K extends PropertyKey> = (
  item: T,
  index: number,
) => K;

export type ValueExtractor<T, V> = (item: T, index: number, arr: T[]) => V;

// First Overload
function keyBy<T, K extends PropertyKey>(args: {
  items: T[];
  key: KeyExtractor<T, K>;
}): Record<K, T>;

// Second Overload
function keyBy<T, K extends PropertyKey, V>(args: {
  items: T[];
  key: KeyExtractor<T, K>;
  value: ValueExtractor<T, V>;
}): Record<K, V>;

// Implementation
function keyBy<T, K extends PropertyKey, V>({
  items,
  key,
  value,
}: {
  items: T[];
  key: KeyExtractor<T, K>;
  value?: ValueExtractor<T, V>;
}): Record<K, T> | Record<K, V> {
  if (value) {
    return items.reduce<Record<K, V>>(
      (acc, curr, index, arr) => ({
        ...acc,
        [key(curr, index)]: value(curr, index, arr),
      }),
      {} as Record<K, V>,
    );
  } else {
    return items.reduce<Record<K, T>>(
      (acc, curr, index) => ({
        ...acc,
        [key(curr, index)]: curr,
      }),
      {} as Record<K, T>,
    );
  }
}

// It doesn't work...
type Foo = {
    bar: string;
    baz: object;
}

declare const items: Foo[];

const x = keyBy({
    items: items,
    key: (x) => x.bar,
    value: (x) => x.baz  // 👈  'x' implicitly has an 'any' type
});

Playground Reproduction

This seems like sort of a major issue, are there any other github issues or places where this issue is tracked? I would love to see a resolution for this in upcoming versions of TypeScript.

[forivall]

This is an issue that has been discussed in the past, and filed under a variety of different ticket numbers. Notably, this has been summarized in a comment: #47571 (comment) . Basically, this is a current design limitation with various workarounds.