Infer tuple types like template literal types do

[DarrenDanielDay]

🔍 Search Terms

Named Tuples
infer tuple element name
function type parameter names
Function Currying

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Infer tuple types like template literal types do.

Example:

type PickedTuple1 = [foo: number, bar: string, null, baz: boolean] extends [
  ...infer Foo, // inferred: [foo: number]
  ...infer Bar, // inferred: [bar: string]
  null, // just a divider
  ...infer Baz // inferred: [baz: boolean]
]
  ? [...Foo, ...Bar, ...Baz]
  : never;
// expected: type PickedTuple1 = [foo: number, bar: string, baz: boolean]
// `... infer Foo`, `... infer Bar` are in a continuous group (length = 2).
// The `null` after group finds a first match at position 2, so the group will try to match tuple range [foo: number, bar: string]
// `... infer Foo` is not the last one in group, so it takes 1 element in the range and creates [foo: number].
// `... infer Bar` is the last one in group, so it takes the rest 1 element in the range and creates [bar: string].
// `... infer Baz` is in another continuous group (length = 1).
// There is nothing after `... infer Baz`, so it will try to match range after `null`: [baz: boolean]
// `... infer Baz` is the last one in group, so it takes the rest 1 element and creates [baz: boolean].

// If we turn above into template literal types, it looks like this:
type PickedTemplate1 = "abnullc" extends `${infer Foo}${infer Bar}null${infer Baz}` ? [Foo, Bar, Baz] : never;
// result: type PickedTemplate1 = ["a", "b", "c"]

// Other examples:

type PickedTuple2 = [foo: number, bar: string, null, baz: boolean] extends [
  ...infer Foo, // inferred: [foo: number]
  ...infer Bar, // inferred: [bar: string]
  ...infer CanBeEmpty, // inferred: []
  null, // just a divider
  ...infer Baz // inferred: [baz: boolean]
]
  ? [...Foo, ...Bar, ...CanBeEmpty, ...Baz]
  : never;
// expected: type PickedTuple2 = [foo: number, bar: string, baz: boolean]
type PickedTemplate2 = "abnullc" extends `${infer Foo}${infer Bar}${infer CanBeEmpty}null${infer Baz}`
  ? [Foo, Bar, CanBeEmpty, Baz]
  : never;
// result: type PickedTemplate1 = ["a", "b", "", "c"]

type PickedTuple3 = [foo: number, bar: string, null, baz: boolean] extends [
  ...infer AllBeforeNull, // inferred: [foo: number, bar: string]
  null, // just a divider
  ...infer Baz // inferred: [baz: boolean]
]
  ? [...AllBeforeNull, ...Baz]
  : never;
// expected: type PickedTuple3 = [foo: number, bar: string, baz: boolean]
type PickedTemplate3 = "abnullc" extends `${infer AllBeforeNull}null${infer Baz}` ? [AllBeforeNull, Baz] : never;
// result: type PickedTemplate3 = ["ab", "c"]

type FailedToMatch = [foo: number, bar: string, null, baz: boolean] extends [
  ...infer Foo,
  ...infer Bar,
  ...infer CanBeEmpty,
  ...infer CannotMatch, // failed to match, group length = 4, but only 2 element before `null`
  null,
  ...infer Baz
]
  ? [...Foo, ...Bar, ...CanBeEmpty, ...CannotMatch, ...Baz]
  : never;
// expected: type FailedToMatch = never
type FailedToMatchTemplate =
  "abnullc" extends `${infer Foo}${infer Bar}${infer CanBeEmpty}${infer CannotMatch}null${infer Baz}`
    ? [Foo, Bar, CanBeEmpty, CannotMatch, Baz]
    : never;
// result: type FailedToMatchTemplate = never

// When `...infer` and `infer` are mixed, only `infer` between `...infer` are treated as a matcher in a continuous group, and matches one element,
// but the tuple element name is erased when using `infer`.
type MixedInfer1 = [a: number, b: number, number, d: number, f: number, g: number, null] extends [
  ...infer A, // 3. range not matched: [a: number, b: number, number, d: number]. A = [a: number]
  infer B, // 3. range not matched: [b: number, number, d: number]. B = number
  ...infer C, // 3. range not matched: [number, d: number]. element name not defined, C = [number]
  infer D,  // 3. range not matched: [d: number]. D = number
  ...infer E, // 4. last one in group, takes the rest, E = []
  infer F, // 2. match any `infer` not in group before concrete type, F = number
  infer G, // 2. match any `infer` not in group before concrete type, G = number
  null, // 1. match concrete type, position = 3
  ...infer H, // 5. H = []
]
  ? [...A, B, ...C, D, ...E, F, G, ...H]
  : never;
// expected: type MixedInfer1 = [a: number, number, number, number, number, number]
// `A`, `B`, `C`, `D`, `E` are in a continuous group, `F` and `G` is not in any continous group.
// `H` is in another continuous group.
// Match steps may be like comments above.

This might be a breaking change to some tuple types infer behavior of existing TypeScript code, but the new behavior is more concrete and more reasonable.

📃 Motivating Example

Currently, when we try to write types for a function currying utility library (such as lodash.curry), the parameter names will be lost in new functions.

This feature allows us to get one element of tuple and keep the element name if present.

type InferFirst<T extends any[]> = 
  T extends [...infer H, ...infer _]
  ? H
  : never

type Ex1 = InferFirst<[foo: number, bar: string, baz: boolean]>
//   ^ before: Ex1 = unknown[]
//   ^ new behavior: Ex1 = [foo: number]

For more discussion, see #49122 (comment).

💻 Use Cases

1. What do you want to use this for?
   Use this for function currying (i.e. std::bind in C++, partial functions in Python) and keep the corresponding parameter names in new function.

2. What shortcomings exist with current approaches?
   Types of bound function created via Function.prototype.bind provide the parameter names perfectly, but we cannot use Function.prototype.bind to bind parameters skipping those in the front.
   Library functions like lodash.curry can infer the correct parameter type but cannot provide the parameter names. So we may make mistakes when parameter types are the same.

3. What workarounds are you using in the meantime?
   No parameter name of original function but generated names like arg_0 instead.