Add type operators that can answer "given function type T, what is the type of its return value when arguments P are passed in?"

Search Terms

overload infer function operator arguments parameters return

Suggestion

// Already possible
type ValueForKey<T, K extends keyof T> = T[K];

// Proposal
type Callable = (...args: any[]) => any;
type ValueForArguments<T extends Callable, A extends paramsof T> = T(...A);

Use Cases

This is a proposal that would help with overloaded function issues like #26591 and would help my type testing library be able to support checks like expectTypeOf(fn).toBeCallableWith(args).

Note that though ValueForKey could be implemented as:

type ValueForKey<T, K extends keyof T> = 
  T extends {[Key in K]: infer U} ? U : never;

The following will only work for non-overloaded functions:

type ValueForArguments<T extends Callable, P extends Parameters<T>> = 
  T extends (...args: P) => infer R ? R : never;

since both the inference from Parameters<T> and the type definition will only consider one of the overloads.

What I'm asking is not for inference to consider multiple overloads, which would be nice but might complexify the implementation of type inference, but direct support for paramsof and T(A1, A2, ...A) type syntax which behaves correctly with overloaded functions.

Examples

interface OverloadedFunction {
  (arg: number): number;
  (arg: string): string;
}

// `number`
type Result1 = OverloadedFunction(number);

// `number | string`
type Result2 = OverloadedFunction(number | string);

// `[number] | [string]`
type Result3 = paramsof OverloadedFunction;

// `number | string`
type Result4 = OverloadedFunction(...paramsof OverloadedFunction)

Also

Given the above, it would also make sense to have something like

type Newable = new (...args: any[]) => any;
type ValueForArguments<T extends Newable, A extends paramsof new T> = new T(...A);

where new T takes the constructor type of T and turns it into a function type

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

The issue names no implementation files, tests, or entry points. Start by reviewing the proposed type syntax and overloaded-function examples, then locate the TypeScript type-checker areas and tests that govern type operators and overload resolution. Done means the proposed operators support the documented examples without changing JavaScript output.