Check index array length

[mdbetancourt]

Search Terms

Indexing, Array, Strict check

Suggestion

Strict check to indexing a array

Use Cases

Safety with arrays usages

Examples

const arr: House[] = .... // same as [] | House[]
arr[0] // throw error
if(arr.length > 0) {
 arr[0] // OK
 arr[200] // throw error
}
const arr2: [House, House] = ...
arr[0] // OK
arr[1] // OK

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code (with a flag)
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[Kingwl]

let a = []
a[1000] = 1 
a.length // 1001

JS AWESOME🤷🏻‍♂️

[RyanCavanaugh]

We go into this a bit at #13778. There isn't a huge amount useful that can be done here while still being sound given the existence of things like pop, push, and clear and the fact that those things can be invoked through indirect operations.

[rubenlg]

push(), pop() and the other arguments provided in this thread did not prevent TypeScript from implementing tuples, even though these operations break tuples completely:

function foo(x: [number, number]) {
 console.log(x[2]); // Expected compiler error: no element at index '2'.
 x.push(5); // Should this even be allowed on a tuple?
 console.log(x[2]); // Still compiler error? Now there is index 2.
 x.pop(); x.pop(); // Should this even be allowed on a tuple?
 console.log(x[1]); // No problem here? Now length is actually 1
}
function bar(x: [number, number], y: number) {
 // Works, but should fail unless y is typed to be 0, 1 or 0|1
 // I'm ignoring this same as tuples ignore it too.
 console.log(x[y]); 
}

Assuming that tuples are still a nice addition to the language, we could leverage them to provide some incremental index safety here, e.g.:

function foo(x: number[]) {
 if (x.length > 0) {
 // New behavior: x becomes [number, ...number[]] rather than just number[].
 console.log(x[1000]) // New behavior, TS only allows indexing at 0.
 }
 if (x.length == 2) {
 // New behavior: x becomes [number, number]
 console.log(x[1000]) // TS error (already happens today for [number, number])
 }
}

So the idea would be:

1. If you declare your array as a regular T[] array, you are on your own when indexing it.
2. If you declare a tuple with a fixed length, you get strict index checking (already happens today).
3. If you declare a tuple with some fixed params and a rest operator, you get strict index checking because you provide some knowledge to the compiler about the length.
4. A check on the length acts as a type guard that transforms the array into a tuple (possibly with rest operator), enabling the checks in 2 and 3.

As an alternative, we could do this only for immutable arrays/tuples. You can't do push, pop or randomly write to those anyway.

Another alternative is to drop 4 (which can still be implemented with custom type guards), but at least implement 3, so we can do:

function hasOneOrMore<T>(x: T[]): x is [T, ...T[]] {
 return x.length > 0;
}

function foo(x: number[]) {
 if (hasOneOrMore(x)) {
 console.log(x[1000]) // Fails because of change 3 above.
 }
}

[Jamesernator]

I would definitely find even just basic cases working better than nothing. At current I use a custom helper that takes an array and returns if it's a tuple of a given length e.g.:

function isLength<T>(arr: T[], length: 0): arr is [];
function isLength<T>(arr: T[], length: 1): arr is [T];
function isLength<T>(arr: T[], length: 2): arr is [T, T];
// etc
function isLength<T>(arr: T[], length: number): arr is T[] {
 return arr.length === length;
}

I use it quite a lot as I'm also using --noUncheckedIndexedAccess, but it'd be super nice to be builtin so I can just use arr.length === 0 rather than using a custom function that only exists for the type system (or more accurately forgetting to use it, and then having an error that value could be undefined). Having <, <=, >, >= would be even better for things like const [first, ...rest] and so on.

[Kingwl]

James Browning (@Jamesernator)

Well... Just for fun:

playground

[Lonli-Lokli]

James Browning (@Jamesernator) I havent checked your sample but from what I see you cannot guarantee that array has at least 1 element, right? So your method should be named 'exactLength', instead of 'atLeast'

[JohnWeisz]

This is more complex unfortunately

You can do this:

let arr = [0, 1, 2];

arr.length = 10;

arr[9] = 9;

And yet...

arr[7] === undefined // true

[rubenlg]

I understand the complexity for mutable arrays. But what about ReadonlyArray? That one doesn't allow mutation (as long as you don't shut down the type checker with any, same as many other TS features).

One issue is that mutable arrays (potentially sparse by accident) are automatically converted to immutable, so this code is still problematic:

function firstElement<T>(x: readonly T[]): T {
 if (x.length === 0) throw new Error('Invalid argument');
 return x[0]; // Seems safe, we have checked length, and it's immutable.
}
let arr = [];
arr[2] = 1;
firstElement(arr); // Should not return undefined

However, given the amount of code I've seen that uses --noUncheckedIndexedAccess and does stuff like this:

if (x.length > 0) return x[0]!; // The compiler doesn't realize I already checked the length???

I'd say --noUncheckedIndexedAccess is already being misused, and is not as effective as it could be.

One possibility to bring this feature to ReadonlyArray in a safer way would be to disable the automatic conversion from mutable to immutable. That would mean that you either do a cast if you are convinced the array is not sparse, or you use an assertion or type guard function, for example:

function notSparse<T>(arr: ReadonlyArray<T|undefined>): arr is ReadonlyArray<T> {
 return arr.every(x => x !== undefined);
}
// This is fine, Array<T> can be assigned to ReadonlyArray<T|undefined> acknowledging that
// it is potentially sparse.
if (notSparse(arr)) {
 firstElement(arr);
}

But this is a breaking change (needs a flag, etc).

Of course, a better solution would be to change JavaScript to add non-sparse arrays to the standard (even if it's just a patch, similar to Object.freeze), which is what we want most of the time anyway. But I haven't seen any interest in this direction.

Alternatively, TypeScript could bridge the gap, with proposals like #24752. Although I acknowledge that this complicates the compiler even more, as it would have to check boundaries for both reads and writes, in subtly different ways.

In the meantime, the pattern I've developed with --noUncheckedIndexedAccess is to replace this:

if (x.length > 0) return x[0]!; // The compiler doesn't realize I already checked the length???

With this:

const first = x[0];
if (first !== undefined) return first;

No need to shut down the type checker, or use the ! operator, and it also works with dynamic indexing.