When the initial element of the tuple is a rest element, it is not possible to correctly infer the type of the initial element.

[13OnTheCode]

🔎 Search Terms

initial element of the tuple is a rest element

🕗 Version & Regression Information

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.2#code/C4TwDgpgBAKgjFAvFA2gOgwZ2AJwJYB2A5igLoA0UBArgLYBGEOl9A9qwDYQCGBpAsACghAEwgBjDtxzRxrAtijScALlhwhQuQuBQAFjxFIlOHCgAMAwVBsB6W1AB6AfiE2o9qAFEAHpHHAECJq2PjEUAA+VHSMOEA

💻 Code

type T1 = [...string[], number, boolean]

declare const arr: T1

const head = arr[0]
   // Actual: string | number | boolean
   // Expected: string | number

🙁 Actual behavior

When the initial element of the tuple is a rest element, it is not possible to correctly infer the type of the initial element.

🙂 Expected behavior

Infer the correct type.

Additional information about the issue

No response

[jcalz]

This is behaving as designed according to #41544 and therefore not considered a bug:

indexing a tuple type beyond its starting fixed elements (if any) yields a union type of all possible element types

Perhaps you'd like to rephrase this as a feature request?

[julienandreu]

From my understanding, your initial type string[] could be an empty array, so Typescript won't be able to determine exactly the type of your first item.

Here is a quick example:
https://www.typescriptlang.org/play?ts=5.3.2#code/C4TwDgpgBAKgjFAvFA2gOgwZ2AJwJYB2A5igLoA0UBArgLYBGEOl9A9qwDYQCGBpAsACghAY1YFsUbjhwAuWAmQo4lXNQikA3ENHjJACx4ATJFJkoADAMFRbAejtQAegH4htqA6gBRAB6QRYAgjeWx8YigAHyo6RhwgA

Let me know if I missed something

[jcalz]

You missed that it couldn't be boolean; you can imagine expanding [...string[], number, boolean] to [number, boolean] | [string, number, boolean] | [string, ...string[], number, boolean] and thus the element at 0 is either number or string. So OP expects string | number, but the feature was implemented to give the union of all element types, string | number | boolean. This is not a bug but it could be considered a missing feature.

[craigphicks]

@jcalz

This is behaving as designed according to #41544 and therefore not considered a bug:

That's out of date with whatever changes were made in 5.0.8 that fixed #49138.
For that reason I would say this is a bug and suggest is be reopened (*but not for the same reason I said before).

See the following examples:

type T1 = [...string[], number, boolean]

const arr1: T1 = [2, true];
const arr2: T1 = ["", 2, true];
const arr3: T1 = [true];

declare const arr: T1;
const head = arr[0]
   // Actual: string | number | boolean
   // Expected: string | number

[jcalz]

I continue to be confused by these comments (especially when they get deleted out of the middle of a discussion). It is by design that T1[0] is string | number | boolean. Yes, that type is wider than it should be, but that's not a bug, it's a design decision. There might well be bugs having to do with leading/middle rest elements in tuple types, but this is not one of them. Maybe I'm wrong, though? If so you'd do better to file a new bug about this rather than asking OP to reopen this one. But my expectation is that it would not be considered a bug. I think I'm probably done with this discussion here, so I hope you'll forgive me if I don't respond to further comments.