In TypeScript, given `class Store<T> { private items: T[] = []; add(item: T): void { this.items.push(item); } }`, when is `T` decided, and what changes if the type parameter is moved onto `add` instead of onto the class?

## Two different scopes A type parameter is always attached to *something*, and the thing it is attached to determines when it is chosen and how long it lasts. - A parameter on the **class** is chosen when the class is instantiated (or when you write the type), and is fixed for the whole lifetime of that instance type. - A parameter on a **method** is chosen at each call, and lasts for that one call. Everything else follows from that. ## Class-level: fixed at instantiation ```typescript class Store<T> { private items: T[] = []; add(item: T): void { this.items.push(item); } all(): readonly T[] { return this.items; } } const s = new Store<string>(); s.add("a"); // ok // s.add(1); // error: number is not assignable to string s.all(); // readonly string[] ``` One decision — `string` — propagates to the private field, the method parameter and the method return type. This is the point of a class-level parameter: it *relates members to one another*. `add` and `all` are not independently typed; they are locked to the same element type because they mention the same parameter. The argument can also be inferred rather than written. If the constructor takes something mentioning `T`, `new Store(["a"])` infers `Store<string>`; when nothing constrains it, the checker falls back to `unknown`, which is a good hint that the parameter should have been supplied explicitly. ## Method-level: fresh per call ```typescript class Formatter { wrap<U>(value: U): { value: U } { return { value }; } } const f = new Formatter(); f.wrap("a"); // { value: string } f.wrap(1); // { value: number } ``` Here the two calls choose different types from the same object, which is correct — nothing about the *object* is element-typed. The parameter relates only the argument to the return type of that call. ## Why moving it breaks the relation Now imagine moving `Store`'s parameter down: ```typescript class BadStore { private items: unknown[] = []; add<U>(item: U): void { this.items.push(item); } } ``` `U` is bound per call and has nowhere to go: the field cannot be `U[]` because there is no single `U` for the object, so it degrades to `unknown[]`. Read-back is now untyped, and every consumer has to narrow. The class-level parameter was carrying the invariant "everything in here is the same type", and moving it deleted that invariant. This is the concrete reason "put the parameter where the relationship lives" is not a style preference. The converse mistake also exists: parameterizing the *class* for something only one method uses forces every construction site to decide a type it does not care about, and often collapses to `Foo<unknown>` in practice. ## Where a class parameter is visible Within the declaration, `T` is in scope for: ```typescript class Store<T> extends Base<T> implements Repository<T> { private items: T[] = []; constructor(initial: T[]) { super(); this.items = [...initial]; } add(item: T): void { this.items.push(item); } } ``` — field types and initializers, the constructor, instance methods, and the heritage clause, where it can be forwarded to a base class or an implemented interface. It is not in scope on the static side, which belongs to the single shared constructor object. ## Two instantiations are two types `Store<string>` and `Store<number>` are distinct types produced from one declaration, and one is not assignable to the other. That is the checker preserving the very relation the parameter was declared to express. There is still only one `Store` at runtime; the distinction is entirely in the type layer and disappears on compilation. ## What interviewers listen for That you answer "when is `T` decided" precisely — once per instantiation, not per call, not at runtime — and that you can articulate the placement rule in terms of *what relates to what* rather than as a recipe. The strongest answers show the failure mode explicitly: move the parameter down and the field's element type has nothing to be, so the class stops guaranteeing anything about its own contents.