In TypeScript, this class compiles with no error: `class G { greeting = this.build(); constructor(private name: string) {} build() { return `hi ${this.name}`; } }`. What does `new G("ada").greeting` hold, and what decides the answer?

## Two ways a class field can be compiled Every TypeScript class with fields is compiled under one of two models, selected by `useDefineForClassFields`: - **Assignment semantics** (`false`): field initializers are turned into `this.x = ...` statements inside the constructor. - **Define semantics** (`true`): fields are emitted as real JavaScript class fields, which the runtime *defines* on the instance before the constructor body executes. The default follows `target`: define semantics from ES2022 upward, assignment semantics below. That is the single most important fact behind this question — the same source compiles two different ways depending on a setting most developers never look at. ## What each mode emits Source: ```ts class G { greeting = this.build(); constructor(private name: string) {} build() { return `hi ${this.name}`; } } ``` With `useDefineForClassFields: false`: ```js class G { constructor(name) { this.name = name; // parameter property first this.greeting = this.build(); // then field initializers } build() { return `hi ${this.name}`; } } ``` `new G("ada").greeting` is `"hi ada"`. With `useDefineForClassFields: true`: ```js class G { name; // generated declaration for the parameter property greeting = this.build(); // runs before the constructor body constructor(name) { this.name = name; // too late for greeting } build() { return `hi ${this.name}`; } } ``` `new G("ada").greeting` is `"hi undefined"`. ## Why the order inverts Under assignment semantics the compiler is free to sequence the statements, and it puts the parameter-property assignments *before* the field initializers — which is what most people intuitively expect from reading the source, since the constructor is where the argument arrives. Under define semantics the compiler has no such freedom. Field definition is a runtime step the engine performs at a fixed point: for a base class, immediately before the constructor body; for a derived class, immediately after `super(...)` returns. The generated `name;` declaration for the parameter property is defined there too, initialized to `undefined`, in declaration order. The actual value only arrives when the constructor body runs, and the body runs last. So under define semantics a parameter property is always assigned *after* every field initializer in the class. ## The compiler catches only the obvious form Write the read directly and TypeScript stops you: ```ts class G { greeting = `hi ${this.name}`; // TS2729: Property 'name' is used before its initialization. constructor(private name: string) {} } ``` TS2729 is a syntactic, single-hop check on the initializer expression. The moment the read goes through a method call, a helper function, a getter, or a callback, the check sees nothing suspicious and the program compiles cleanly. That is exactly the shape in the question, and it is why this bug reaches production: the source looks fine, the type-checker is silent, and the behaviour depends on a compiler option. ## Derived classes The same rule holds with inheritance, with `super(...)` as the pivot. Given: ```ts class Base { constructor(protected id: string) {} } class Sub extends Base { label = "L"; constructor(id: string, private extra: number) { super(id); } } ``` under define semantics `Sub`'s fields — the generated `extra;` and then `label`— are defined right after `super(id)` returns, and `this.extra = extra;` runs afterwards in the body. Under assignment semantics the constructor reads `super(id); this.extra = extra; this.label = "L";`. Note also that `Base`'s own parameter property is assigned during `super(id)`, so it *is* available to `Sub`'s field initializers in both modes. ## How to avoid the trap Three defences, in order of preference: 1. **Do not read a parameter property from a field initializer.** If a field's value derives from a constructor argument, compute it in the constructor body after the arguments are in place: `constructor(private name: string) { this.greeting = this.build(); }` with `greeting` declared but uninitialized. 2. **Make the derived value a getter** — `get greeting() { return this.build(); }` — so it is computed on read and no ordering exists to get wrong. 3. **Know which mode your project is in.** Check `target` and any explicit `useDefineForClassFields`, and be aware that raising `target` to ES2022 silently flips the semantics of every class in the codebase. ## What the interviewer is looking for A weak answer says `"hi ada"` and stops, because that is what reading the source top-to-bottom suggests. A strong answer refuses to give a single value: it names `useDefineForClassFields`, explains that define semantics run field initializers before the constructor body while assignment semantics interleave them after the parameter-property assignments, and adds that the type-checker's TS2729 guard only covers a direct read. That last point is what separates someone who has read about the flag from someone who has debugged this.