Repository: TypeScript
Issue: Evaluate mathematical expression of indices when indexing tuples
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

tuple bounds, tuple index computing, bound checking removal, noUncheckedIndexedAccess

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Currently (version 4.1), Typescript is able to deduce that an array access to a tuple is within bounds if it is indexed by an integer literal union type that fits within the array, e.g.:
```typescript
type I = 0 | 1 | 2;
function access(i: I, a: [string, string, string]) {
    return a[i];
} // type: string, even with noUncheckedIndexedAccess = true
```

However, as soon as there is an operation on the indexing variable, even trivial, Typescript falls back to inferring `number`. Therefore, the following code:
```typescript
type I = 0 | 1;
function access(i: I, a: [string, string, string]) {
    return a[i + 1];
} // type: string | undefined, when noUncheckedIndexedAccess = true
```

In principle, Typescript could reason a bit deeper on the set of possible integer values when going through operations, especially for the trivial ones like in my example. If there is a lot of values in the union, it might be computationally expensive, but in that case a conservative bound analysis would already be enough for most uses cases (see #15480).

## 📃 Motivating Example

The proposed feature would at minimum allow:
```typescript
type I = 0 | 1;
function access(i: I, a: [string, string, string]) {
    return a[i + 1];
}
```
and, if possible, use cases such as:
```typescript
type Vector = [number, number];
type Matrix = [number, number, number, number];
const Range = [0, 1] as const;
function mult(m: Matrix, v: Vector) {
    let ret: Vector = [0, 0];
    for (const i of Range) {
        let acc = 0;
        for (const j of Range) {
            acc += v[j] * m[i * 2 + j];
        }
        ret[i] = acc;
    }
    return ret;
}
```
and, if `Vector` and `Matrix` can be aliases to fixed-size typed arrays (see #18471) in addition to tuple, it would be wonderful.

## 💻 Use Cases

That feature would be very useful in conjunction with `noUncheckedIndexedAccess` obviously, but also with a way to statically type the length of `TypedArray` (see #18471) for use in mathematical and graphics code. But even without typed arrays, it would still be useful in day-to-day code. I'm experimenting in switching our 45 kloc Typescript code base to `noUncheckedIndexedAccess = true` and that feature would increase type safety in several places.