In TypeScript, why does `obj[key] = obj[key] + 1` fail to compile inside `function bump<T, K extends keyof T>(obj: T, key: K)`, and how do you type a helper that only accepts keys whose property is a number?

## The failing version ```ts function bump<T, K extends keyof T>(obj: T, key: K) { obj[key] = obj[key] + 1; // error: The left-hand side of an arithmetic operation must be of // type 'any', 'number', 'bigint' or an enum type. } ``` The signature is fine for *callers*. It fails for the *implementation*, and understanding why is the point of the question. ## Deferred types Inside a generic function body the type parameters are not yet bound to anything. `T[K]` cannot be evaluated, so the checker keeps it as a symbolic, **deferred** indexed access. All it knows about that type is its constraint: `T[K]` is bounded by the union of `T`'s property types, and since `T` is unconstrained here, that bound is effectively `unknown`. Nothing lets it conclude `number`. The same reasoning blocks the write. Assigning a concrete `number` into `obj[key]` needs `number` assignable to `T[K]`, and for an arbitrary `T` it is not — the caller might have instantiated `T` with `{ hits: string }`. ## Constrain in the other direction The pattern `<T, K extends keyof T>` derives the key from the object. When you need a *requirement on the value type*, relate them the other way round: derive the object's constraint from the key. ```ts function bump<K extends string, T extends Record<K, number>>( obj: T, key: K, ): void { obj[key] = obj[key] + 1; } const stats = { hits: 0, misses: 0 }; bump(stats, "hits"); // ok bump({ name: "a" }, "name"); // error: string is not assignable to number ``` `K` infers the literal `"hits"` because its constraint is `string`, then `T` must satisfy `Record<"hits", number>` — a type with a `hits` property of type `number`. `Record` is a built-in utility type, so nothing custom is needed. Inside the body the constraint tells the checker that reading `obj[key]` yields `number`, and that a `number` may be written back. Either ordering of the two type parameters works; what matters is that one constraint mentions the other parameter. ## Why not just cast? A common but weaker answer is `(obj[key] as number) + 1` and `obj[key] = value as T[K]`. That silences the checker at exactly the point where it was telling you something true: the signature admits objects whose property is not a number. The assertion moves the failure to runtime, and it does not stop `bump({ name: 'a' }, 'name')` from compiling. Constraints fix the contract; assertions hide the mismatch. ## Related friction to expect Deferred types cause similar complaints elsewhere. Calling a method on `T[K]`, spreading it, or comparing it with `===` against a concrete literal all fail for the same reason: without a constraint the checker has no information. The remedy is always the same shape — say more in the constraint, so the body has something to reason from. Note also that the object's constraint here does not forbid extra properties; `Record<K, number>` is a minimum requirement, and `{ hits: 0, label: 'x' }` still satisfies it. ## Erasure, as always None of this affects the emitted JavaScript, which is a read, an addition and a write. The constraint exists only so the compiler can reject the call sites that would break that code. ## Interview framing "`T[K]` is deferred while `T` is a type parameter, so the checker only knows its constraint, which here is nothing useful — hence the arithmetic error. If I need the value to be a number, I put that in the constraint by requiring the object to be a `Record<K, number>` rather than deriving the key from an unconstrained object."