In TypeScript, `if (typeof obj[key] === "string") { obj[key].toUpperCase(); }` compiles when `key` is declared `const key = "a"`, but fails when `key` is a `let`. Why does the declaration of the key decide this, and why is the narrowing you do get still unsound?

## Narrowing works on references, not on values When the checker narrows, it records a fact about a *reference* — a syntactic path such as `x`, `x.y`, or `x.y.z`. At a later use it asks whether the reference there is the same path, and if so applies the recorded fact. This is why narrowing `user.profile` does not narrow `getUser().profile`: a call expression is not a stable path. ## Element accesses as references TypeScript 4.7 extended that matching to element accesses, so `obj[key]` can be narrowed and stay narrowed. The requirement is that the index expression be effectively constant *and* have a literal type — a string, number or unique symbol literal written inline, or a `const` variable / `readonly` property whose type is such a literal. ```ts declare const obj: Record<string, string | number>; const key = "a"; // type "a" if (typeof obj[key] === "string") { obj[key].toUpperCase(); // ok since TypeScript 4.7 } ``` The canonical example from the release used a symbol key, which behaves the same way: ```ts const key = Symbol(); const numberOrString = Math.random() < 0.5 ? 42 : "hello"; const o = { [key]: numberOrString }; if (typeof o[key] === "string") { o[key].toUpperCase(); } ``` ## Why `let` breaks it Two separate things go wrong at once. First, **widening**. A `const` initialised with a string literal keeps the literal type `"a"`; the same initialiser on a `let` widens to `string`, because the binding is expected to hold other strings later. The checker needs a literal to form a stable reference path — `string` names a whole family of slots, not one. Second, **mutability**. Even if the type were preserved, a `let` can be reassigned between the check and the use, at which point the two `obj[key]` expressions genuinely denote different properties. Rather than analyse whether an assignment occurs, the checker declines. ```ts let key = "a"; // type string if (typeof obj[key] === "string") { obj[key].toUpperCase(); // error: Property 'toUpperCase' does not exist // on type 'string | number' } ``` The same reasoning covers numeric indexes: `const i = 0` has the literal type `0` and narrows `arr[i]`, while `let i = 0` widens to `number` and does not. ## The unsoundness you keep even when it works Narrowing on any property or element access is a deliberate compromise. The checker invalidates a recorded fact when it sees a direct assignment to that same reference, but it does not attempt to model what arbitrary code might do to the object: ```ts function reset(o: Record<string, string | number>) { o.a = 0; } if (typeof obj[key] === "string") { reset(obj); obj[key].toUpperCase(); // still typed string; throws at run time } ``` The same applies to a property implemented as a getter that returns a different value on each read, and to code that runs concurrently between the two statements in an async function. None of this is a bug report — modelling it soundly would require the checker to assume every call invalidates every narrowing, which would make the feature useless. There is a second, related caveat about element access in general: by default the checker assumes an indexed read returns the declared value type rather than possibly `undefined`, which is why a missing key produces a confident type. The compiler flag `noUncheckedIndexedAccess` changes that assumption; it belongs to the strictness surface rather than to narrowing itself. ## Working with the limitation The reliable move is to stop re-reading the slot: pull the value into a `const` and narrow that local instead. ```ts const value = obj[key]; if (typeof value === "string") { value.toUpperCase(); // narrowing on a local const — no re-read, no staleness } ``` This works regardless of how `key` is declared, keeps the narrowed value stable across intervening calls, and reads more plainly. Reach for element-access narrowing when a local copy would be awkward, and treat it as an ergonomic convenience rather than a guarantee.