Add Length Parameter to typed arrays

[HyphnKnight]

The goal is pretty straight forward, since typed arrays have a fixed length it would be a more accurate and helpful type it you could specify length. Then you could get complaints if you try to assign or access a higher index or use a array of the incorrect length.

Code

type Vector2d = Int32Array<2>;
type Vector3d = Int32Array<3>;
type Matrix = Int32Array<16>;

const add =
  (vecA:Vector2d) =>
    (vecB:Vector2d, target:Vector2d = new Int32Array(2) ):Vector2d => {
      target[0] = vecA[0] + vecB[0];
      target[1] = vecA[1] + vecB[1];
      return target;
    };

const add3d =
  (vecA:Vector3d) =>
    (vecB:Vector3d, target:Vector3d = new Int32Array(3) ):Vector3d => {
      target[0] = vecA[0] + vecB[0];
      target[1] = vecA[1] + vecB[1];
      target[2] = vecA[2] + vecB[2];
      return target;
    };

const position = new Int32Array(2);
const position3d = new Int32Array(3);
const velocity = new Int32Array([1,1]);
const velocity3d = new Int32Array([1,2,3]);

add(position)(velocity, position);
const newPosition = add(position)(velocity);

add3d(position3d)(velocity3d, position3d);
add(position3d)(velocity3d, position3d); // Fails due to incorrect array length

[mhegazy]

you can already do this today with:

type Vector2d = MyInt32Array<2>;
type Vector3d = MyInt32Array<3>;
type Matrix = MyInt32Array<16>;

interface MyInt32Array<T extends number> extends Int32Array { 
	length: T;
}

interface Int32ArrayConstructor {
	new<T extends number>(length: T): MyInt32Array<T>;
}

[mhegazy]

I am not sure of the utility of pushing this change into the standard library though.

[HyphnKnight]

My only criticism of that suggestion is that it doesn't handle the accessing or setting of an index beyond the length.

Well that and having to create custom array types to mimic the existing data types.

[mhegazy]

My only criticism of that suggestion is that it doesn't handle the accessing or setting of an index beyond the length.

Array is not handled differently in the type system. so it will be strange if we start paying attention to length. on any rate we have similar requests in the context of tuples, see #6229.

[bitjson]

A custom type guard (like @mhegazy's above) is definitely a good immediate solution, but I think it would be a huge improvement for TypeScript to specifically track the length of typed arrays.

For normal arrays, this would expand the scope of type-checking significantly, since array lengths can be modified after creation. However, typed arrays have fixed sizes at creation and can then be treated as a unique primitive.

Current Example

Here's an obvious bug which isn't currently caught at compile time:

function specialTransform (array: Uint8Array) {
    if (array.length !== 4) {
        throw new Error('This function is only for 4-byte Uint8Arrays.')
    }
    return new Uint8Array([array[0] + 1, array[2], array[3] - 1, array[4]])
}

const bytes = new Uint8Array([1, 2, 3]);

// Will always throw an error at runtime, but can't be identified at compile time:
specialTransform(bytes);

This code could never work, and the thrown error in specialTransform should never happen in production. It's only purpose is to inform the programmer during debugging that they are using specialTransform incorrectly.

This could be made harder-to-mess-up with a custom type guard:

interface SpecialType extends Uint8Array {
  readonly length: 4;
}

export function brandSpecialType(array: Uint8Array): SpecialType {
    if (array.length !== 4) {
        throw new Error('This function is only for 4-byte Uint8Arrays.')
    }
  return array as SpecialType;
}

function specialTransform (array: specialType) {
    return Uint8Array([array[0] + 1, array[2], array[3] - 1, array[4]])
}

// the user still needs to 
const bytes = Uint8Array([1, 2, 3]);

// Runtime error happens a little earlier, but still not at compile time:
const mySpecialType = brandSpecialType(bytes);

specialTransform(mySpecialType);

This is marginally better in some situations, but requires a lot more custom infrastructure. If I'm writing a library that operates on sets of specifically sized typed arrays (like a cryptographic library), I can't provide both flexibility and strict typing. (See bitcoin-ts's Secp256k1 for an example.)

(Please let me know if I'm missing a better solution here.)

I believe I can either allow the developer to pass my functions a simple Uint8Array (and type-check at runtime to make sure they did it right), or I can export infrastructure for "creating" SpecialTypes, which are just ways of tightening the type of the length parameter.

What I would like to see

IMO, it would be ideal if TypeScript had the ability to track the length of typed arrays, and check them using simple expressions. Something like:

function specialTransform (array: Uint8Array<length === 4>) {
    return new Uint8Array([array[0] + 1, array[2], array[3] - 1, array[4]])
}

// works
specialTransform(new Uint8Array([1, 2, 3, 4]));

// ts error: Argument of type 'Uint8Array<{length: 3}>' is not assignable to parameter of type 'Uint8Array<length === 4>'.
specialTransform(new Uint8Array([1, 2, 3]));

Along with allowing certain examples to be fully type-checked, this would allow significantly better interoperability between libraries which deal with typed arrays.

---

(Last note: I'm sure there's a more general feature that could be implemented and used to add this functionality to TypedArrays, but I'm not knowledgable enough to discuss the general case. I think it may be similar to the Tag types discussion, though since typed arrays are first-class JavaScript features, and for the other reasons above, I think TypeScript should have this kind of checking for typed arrays built-in.)

[KB1RD]

IMO, it would also be useful to be able to enforce non-zero array length.

[stephanemagnenat]

This feature would be very useful now that noUncheckedIndexedAccess has landed (#39560). Indeed, especially when dealing with geometric and WebGL code, one easily has Float32Array and TS has no way to check when an integer literal is used to access it within bounds. Adding this feature and letting TS use it in conjunction with noUncheckedIndexedAccess would improve code safety.

[stephanemagnenat]

Actually, it is possible to do that with recent Typescript versions:

type FixedSizeArray<T, N extends number> = N extends N ? number extends N ? T[] : _FixedSizeArray<T, N, []> : never;
type _FixedSizeArray<T, N extends number, R extends unknown[]> = R['length'] extends N ? R : _FixedSizeArray<T, N, [T, ...R]>;

type KnownKeys<T> = {
	[K in keyof T]: string extends K ? never : number extends K ? never : K
} extends { [_ in keyof T]: infer U } ? U : never;
type Float32ArrayWithoutIndex = Pick<Float32Array, KnownKeys<Float32Array>>;

type FixedSizeFloat32Array<N extends number> = FixedSizeArray<number, N> & Float32ArrayWithoutIndex;

...but it is cumbersome and feels a bit hacky, it would be wonderful if Typescript would provide first-hand support for the compiler to see typed arrays as fixed-size arrays.

[ddadamhooper]

We at Datadog had this problem with gl-matrix (which uses Float32Array) when we turned on noUncheckedIndexedAccess in some parts of our codebase. We needed a solution for this simple pattern:

type Vec2 = [x: number, y: number] | Float32Array;

const drawPoint([x, y]: Vec2) {
    console.log(x + y);
    // with `noUncheckedIndexedAccess`, x and y are now `number | undefined`!
}

We patched the gl-matrix index.d.ts to remove Float32Array from the Vec2 type. Even though we sometimes use Float32Array -- we're duck-typing! See toji/gl-matrix#464

We considered hacks like type Vec2 = [x: number, y: number] | Float32Array & { length: 2 }, and FixedSizeFloat32Array ... but those approaches sacrifice TypeScript's helpful tuple destructuring error ([x, y, z]: Vec2 should cause a type error) and we didn't see a strong enough upside.