A TypeScript module has `let current: User | null = null;` and an exported `reset()` that sets it to null. Another function writes `if (current !== null) { reset(); console.log(current.name); }` — this compiles but throws at runtime. Why does the compiler allow it, and how would you make the code safe?

## What the compiler actually checks Control-flow analysis is **intraprocedural**: when checking a function, TypeScript walks that function's own flow graph. A call node in that graph is just a node — the compiler knows the callee's *signature*, and nothing about what its body does to variables outside it. ```ts // module scope export let current: User | null = null; export function reset(): void { current = null; } export function greet(): void { if (current !== null) { reset(); console.log(current.name); // compiles — narrowing survived the call } } ``` The `if` puts `current` at `User` on the true edge. Between the check and the read there is no assignment *in this function*, so the narrowing is still in force at `current.name`. At runtime `reset()` has already set the binding to `null`, and the property read throws. ## Why the compiler is built this way The alternative is to assume any call may reassign any reachable mutable binding. That is the sound choice, and it is unusable: every narrowing would be discarded at the first function call, including calls that obviously cannot touch the variable. Real code would be forced back into re-checking after every statement, or into assertions everywhere — which is strictly worse for safety, because assertions are unchecked. So TypeScript takes the pragmatic position: **narrowing is invalidated by assignments the analysis can see**, not by assignments it must imagine. That includes assignments in the current function, and re-narrowing on reassignment. It excludes side effects hidden behind calls. This is one of a small family of deliberate soundness holes the language documents and expects engineers to know — the compiler is a very good assistant, not a proof system. ## Recognising the shape in review The pattern has three ingredients, and all three must be present: 1. a **mutable** binding (`let`, or a mutable property) that 2. lives **outside** the function doing the check — module scope, a class field, a captured variable — and 3. is read **after** a call that can reach it. A `let` that is local to the function and never captured cannot be hit: nothing else can reassign it, so the analysis sees every assignment there is. That is why the bug clusters around module singletons, caches, and "current user / current request / current connection" style state. ## The fixes, weakest to strongest **Snapshot into a `const`.** The minimal change, and it is genuinely sound: ```ts export function greet(): void { const user = current; // read once if (user === null) return; reset(); console.log(user.name); // safe — user cannot be reassigned } ``` The narrowing now applies to a binding that no other code can touch. Note the semantic change you are accepting: `user` is the value as of the read, so if `reset()` were meant to affect what this function sees, it no longer does. That is usually what you wanted, but say it out loud. **Pass the value instead of reading the global.** Make the dependency a parameter (`greet(user: User)`), so the caller resolves the state once and the function has no ambient binding to go stale. **Remove the mutable module binding.** Export a getter over private state, or hold the state in an object owned by a caller. A module-level `let` that anything can reassign is a hazard independent of TypeScript: it makes every reader's assumptions depend on execution order. ## Related traps worth naming - **Object properties behave the same.** `if (obj.value !== null) { doSomething(); obj.value.length; }` compiles for the same reason — the compiler does not model what `doSomething` may write to `obj`. - **A non-null assertion is not a fix.** Writing `current!.name` silences the same code with no runtime check at all; it converts a compiler bug report you never got into an assumption you documented as safe. - **`readonly` does not help here.** It constrains writes through that reference at compile time; it does not stop `reset()` from writing through its own. ## What to say in an interview Name the mechanism (intraprocedural flow analysis, narrowing invalidated only by visible assignments), state that it is a chosen unsoundness with a stated rationale rather than a bug, give the snapshot-into-`const` fix, and then make the design point: the type system is telling you something about the code even when it says nothing — mutable ambient state is exactly the shape whose correctness a checker cannot underwrite.