Skip to content

Tuples: maintaining type-param in the type of it's itemsΒ #61750

Open

Description

πŸ” Search Terms

for-of, T[number], tuple (I couldn't find more specific search terms).

βœ… Viability Checklist

⭐ Suggestion

When a function takes an array/tuple as a type-parameter, e.g.

function foo<T extends readonly unknown[]>(items: T): void;

When accessing the items of this array (items[0]), they are "resolved" to the type defined for the generic, e.g., unknown in this example, but should be kept unresolved so that they show up as T[number] | undefined.

This becomes an issue once a function takes more than one array like this, for example, if it wants to use the tuple/array shape as a param in the output. This can lead to real runtime errors where TypeScript isn't providing enough safety.

This is also relevant for for-of loops iterating over items

for (const item of items) {
  console.log(item);
  //          ^? unknown, can be T[number]
}

πŸ“ƒ Motivating Example

The following example passes typescript checking but fails in runtime and throws exceptions when trying to access methods of strings on a number, and vice-versa.

type DoubleMap<
  T extends readonly unknown[],
  S extends readonly unknown[],
  RT,
  RS,
> = [...{ [I in keyof T]: RT }, ...{ [I in keyof S]: RS }];

function doubleMap<
  T extends readonly unknown[],
  S extends readonly unknown[],
  RT,
  RS,
>(
  t: T,
  s: S,
  mapperT: (item: T[number]) => RT,
  mapperS: (item: S[number]) => RS,
): DoubleMap<T, S, RT, RS> {
  const output: (T[number] | S[number])[] = [];

  for (const itemT of t) {
    // Oops, we got the mappers wrong, we are calling mapperS with an item from T
    output.push(mapperS(itemT));
  }

  for (const itemS of s) {
    // ...And here we are calling mapperT with an item from S
    output.push(mapperT(itemS));
  }

  // @ts-expect-error [ts2322] -- TypeScript can't tell we finished building the output, this is fine...
  return output;
}

const result = doubleMap(
  //  ^? [boolean, boolean, boolean, number, number, number]
  ["a", "b", "c"] as const,
  [1, 2, 3] as const,
  (item) => item.startsWith("a"),
  (item) => item.toPrecision(1),
);

https://www.typescriptlang.org/play/?noUncheckedIndexedAccess=true&noUnusedLocals=true&noUnusedParameters=true&noPropertyAccessFromIndexSignature=true&noImplicitOverride=true&noFallthroughCasesInSwitch=true&exactOptionalPropertyTypes=true#code/C4TwDgpgBAIg9gVwEYBsIFkCGYA8AoKKAFSggA9gIA7AEwGcoAnCTGuKlEKBKgayrgB3KgG0AugBoCUAMqkK1ekxZsOXHvyGjJ0gEpEphXTKkA+KAF4oIgHR2A3tYCSUAJZUovCCDgAzYmIAXFD6UAC+ElB2No4iLu6e3n6yQSFyYWIA3Hh4vjwAxsCu7FBsyGhYuNIk5JS0DMys7JzcfALC4oay8nVKjaotGu3aXfqjJnimABTSwMEG0nTBE4QAttiQjETBU66Uq-MiVAirSBCMYgCUluZj0utgmzI7exAHskcnZxfXFrcTl2C8HKGGwOAMskiYzS5ns0ny7DowCgiGAYAQcygUyIn1O5zEUAAPh9jnifuJLNYsjlCL44IwsQiqEi3PsSMlgNc4YRCAB6XlQADycDAdEigmgAHM4MjgAALaAPTYMQSMdiS8XQTDMKD5TAoFDuSVQJXnOSCPZyqCYDyvVZQXxq+1EaSEVHo4A2dF0OVTU2MGS7NmXS7ZQhhGkO+mMxHIu1yZJ0LmuqD8qJ2ACCtCgCp1EutOr1BqNJo25xIFvl1tt+wdTtkKfdGK9CB9frLWyDbxkIbD4UjaYAAsA6ABaciQQrjxhqhkiEcAJgAzAuFwTR6PiOAIDJ8oxXGBkXqqAByWUQA1QfO+dyuH0QGhQJAIVwoGgl+XQJvASLyu9uBgbyoCBomkZhgAQRgPG-bIIzwJkWWYOgEBQZErDKVBQTAGY+QFKAAD0AH5pBEAAiTBSMiUikEoqBSPyUiCUwBgEJ-EiAEZIgXSIlyYljYy6LtVl+cw7RsJFtRHAB1S0pnI0jLkEu0RNZN4bGAOAAAVmHyO9iioKZ2MUvBQzwIA

Live example:

https://codesandbox.io/p/sandbox/tgr8pm

πŸ’» Use Cases

  1. What do you want to use this for?
  2. What shortcomings exist with current approaches?
  3. What workarounds are you using in the meantime?

Activity

  1. changed the title [-]Tuples: maintaining type-param when accessing items of tuple type-param[/-] [+]Tuples: maintaining type-param in the type of it's items[/+] on May 22, 2025
  2. jcalz commented on May 22, 2025

    @jcalz
    Contributor

    Similar suggestion in #33181: currently indexing into generic objects with non-generic keys prematurely widens the generic to its constraint. In this case the key is number or a numeric literal type.

  3. RyanCavanaugh commented on Jun 5, 2025

    @RyanCavanaugh
    Member

    I'd be interested to see a PR here. It seems plausible but might need additional logic to ensure that e.g. x[0] is still assignable to the index type

  4. eranhirsch commented on Aug 3, 2025

    @eranhirsch
    Author

    Ryan Cavanaugh (@RyanCavanaugh) - this is a broader issue, I've found another repro with function generics too. I don't know if it's worth opening a new issue for this, or if to broaden the description and title for this issue so it better encapsulates the whole problem.

    function map<F extends (item: unknown) => unknown>(
      data: Parameters<F>[0][],
      mapper: F,
    ): ReturnType<F>[] {
      const out: ReturnType<F>[] = [];
    
      for (const item of data) {
        const mapped = mapper(item);
        //    ^? const mapped: unknown
        // ...but we'd get more value if it were typed instead as ReturnType<F>.
    
        out.push(mapped);
      }
    
      return out;
    }

    https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABAWwIYAcA8AxRBTADyjzABMBnRAChmOQC5FwBrMOAdzAEpEBeAPiZhWHMPyoAoRIlKooqRgAVUAJ1TI8xFeRz8A2gAYAunqMAaKSgzo8KxtgtdGAJU0gVYACoBPG7tOIAN6WEAjkUIhwIFAubh4+ftj6RnyIpgDcEpbAcCrUoWDhiLR4yJHAMnKoPMHS0gVFaOg2pKlNNiqSdXUA9D3SAHoA-JbdJcgW3dJ9iMOjiFyZ3VFQAHToIOQAFlTteKSLlgC+WdIqcUgrmSdAA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Experimentation NeededSomeone needs to try this out to see what happensSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions