`[...T[], T]` does not extend `[T, ...T[]]`

🔎 Search Terms

homogeneous tuple, non-empty array, assert not empty

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about array/tuple

⏯ Playground Link

https://www.typescriptlang.org/play/?jsx=0&ts=5.7.0-beta#code/C4TwDgpgBAKhDOwoF4oG0B0WCMaC6ANFNnlBAB7AQB2AJvOtkVhrnqQPxTABOArtABcUAGYBDADbwIAbgBQAegVQVAPQ5zNAYwD21RFACW8AKIBbMKBRQAPDAB8ACnLxhMfAEphLow3wp7KABCFwwJGgBzYAALOV19JAkxA1Q7JxdhNBhmLHd2DwCoFzRQ8Ooo6KgAWmI8eTlQSCgAMR0da38AH3RqPjMAIwgeHIxegaH8OrlaCC0knmh4gwyWtvkZubEFqCWkEFcoMcGefE1DEUcg43NLEGd4DwKAbzkVFV2oAC8D1vbUTCw+yISUQ9w8pGSOz0iHkAF8gA

💻 Code

type Test = [...1[], 1] extends [1, ...1[]] ? true : false;
//   ^? type Test = false

In context:

const isEmpty = <T>(xs: T[]): xs is [] => !xs.length
const last = <T>(xs: [T, ...T[]]) => xs[xs.length - 1];

type Foo = [] | [number, ...number[]];
declare const xs: Foo;
declare const ys: number[]

if(!isEmpty(xs)) {
    const zs: Foo = [...ys, last(xs)] as const;
//        ~~
// Type '[...number[], number]' is not assignable to type 'Foo'.
//  Type '[...number[], number]' is not assignable to type '[number, ...number[]]'.
//    Source provides no match for required element at position 0 in target.(2322)
}

🙁 Actual behavior

For a homogeneous tuple, [...T[], T] and [T, ...T[]] are the same thing.

TS fails to recognise that in the in-context example: it is saying that [...ys, last(xs)] could be missing a required number but it can't because last(xs) is the required number that it is looking for. The only issue is that it is of type [...number[], number] and since [...T[], U] is not the same thing as [T, ...U[]], It chokes.

🙂 Expected behavior

Test should be true and zs: Foo should not be a type error.

Additional information about the issue

I wish !isEmpty could narrow T[] to [T, ...T[]].

Using a isNotEmpty helper with Foo defined as number[] would solve this specific case but in the wild it would force me to call it like so !isNotEmpty(xs) in many places, which is terrible for readability.

It would be possible in the in-context example to define Foo as [] | [number, ...number[]] | [...number[], number] and last as <T>(xs: [T, ...T[]] | [...T[], T]) =>T but nobody in the world is doing that and I would be splitting hair alone in my basement not being able to use any library.

I think I trip over this more often in recursive logic.