Also, IMO, it doesn't feel very useful if we can only generate tuples having the same type in all positions. Maybe in the next major version we should change the API to simply accept a tuple, like:

export type FixedLengthArray<TArray> = Except<TArray, ArrayLengthMutationKeys>;

If I understand correctly, the only purpose of this type is to remove methods like 'push', 'pop' from a tuple, right?

Should these tests pass?

expectAssignable<string[]>({} as FixedLengthArray<string, 3>);

declare const a: FixedLengthArray<string, 3>;
declare const i: number;
expectType<string>(a[i]);

A few more tests to add:

expectType<3>({} as FixedLengthArray<string, 3>['length']);
expectType<string>({} as FixedLengthArray<string, 3>[number]);

Also, IMO, it doesn't feel very useful if we can only generate tuples having the same type in all positions. Maybe in the next major version we should change the API to simply accept a tuple, like:

That sounds more like a different type. This type is homogeneous while your suggestion is heterogeneous. Could maybe be:

export type FixedTuple<T extends unknown[]> = Except<T, ArrayLengthMutationKeys>;

?

That sounds more like a different type. This type is homogeneous while your suggestion is heterogeneous. Could maybe be:

True, but now that we have BuildTuple available, we can create homogeneous tuples simply by using FixedTuple and BuildTuple, like:

type RGB = FixedTuple<BuildTuple<3, number>>

So, does it still make sense to have two separate types?

Should these tests pass?

expectAssignable<string[]>({} as FixedLengthArray<string, 3>);

This shouldn't, because string[] has methods like 'push', 'pop', while FixedLengthArray<string, 3> does not. This is similar to why readonly string[] is not assignable to string[]. Added the following test case instead:

expectAssignable<readonly string[]>({} as FixedLengthArray<string, 3>);

declare const a: FixedLengthArray<string, 3>;
declare const i: number;
expectType<string>(a[i]);

This one is related to the following point:

• Added number to ArrayLengthMutationKeys, so that out-of-bounds access is prevented. I can't think of a case where this would break something.

You can't index the array using the non-literal number type, because number could be something out-of-bounds. Like, in your example, i could hold a value of 10 at runtime.

A few more tests to add:

expectType<string>({} as FixedLengthArray<string, 3>[number]);

This test is similar to the above. LMK if you see any issues with removing number.

So, does it still make sense to have two separate types?

Yeah, discoverability. FixedTuple is more of a building block.

• Added number to ArrayLengthMutationKeys, so that out-of-bounds access is prevented. I can't think of a case where this would break something.

I'll add a note regarding this in the doc.

How about this?

expectType<string | undefined>({} as FixedLengthArray<string, 3>[number]);

How about this?

expectType<string | undefined>({} as FixedLengthArray<string, 3>[number]);

Yeah, I was also thinking about this. I think this is better. So, instead of removing the number index signature, let's make it readonly. This way, we could still read from out-of-bounds indices but not write to them.

This also helps when we create non-tuples using FixedLengthArray, because if we remove the number index signature, then we would not be able to access any index from something like FixedLengthArray<string, number>.

Yeah, I was also thinking about this. I think this is better. So, instead of removing the number index signature, let's make it readonly. This way, we could still read from out-of-bounds indices but not write to them.

Turns out it's not that straightforward.

1. If we add the number index signature with an extra | undefined, like:

   export type FixedLengthArray<Element, Length extends number> =
       Except<BuildTuple<Length, Element>, ArrayLengthMutationKeys | number>
       & {readonly [x: number]: Element | undefined};

   Then the following test cases break:

   expectAssignable<readonly [string, string, string]>({} as FixedToThreeStrings);
   expectAssignable<readonly string[]>({} as FixedToThreeStrings);

   

2. If we just make the number index signature readonly w/o adding the extra | undefined, like:

   export type FixedLengthArray<Element, Length extends number> =
       Except<BuildTuple<Length, Element>, ArrayLengthMutationKeys | number>
       & {readonly [x: number]: Element};

   Then out-of-bounds accesses have the extra | undefined only when noUncheckedIndexedAccess is enabled.

   // @noUncheckedIndexedAccess: true
   const outOfBounds = fixedToThreeStrings[3];
   //=> string | undefined

   // @noUncheckedIndexedAccess: false
   const outOfBounds = fixedToThreeStrings[3];
   //=> string

   And also, if we directly index from the type, the result never has the extra | undefined irrespective of the noUncheckedIndexedAccess setting. This seems to be a TS quirk, I was expecting noUncheckedIndexedAccess to affect type-level accesses as well.

   type OutOfBounds = FixedToThreeStrings[3];
   //=> string

So, I have come up with a hybrid approach wherein we don't add the number index signature for tuples, so out-of-bounds accesses simply error, and for non-tuples (which should be a rarer use case) we add the number index signature similar to point no. 2.

@sindresorhus Made significant changes to this PR, also updated the JSDoc completely, please review.

Updated the PR, here's a quick summary: