In a TypeScript interface, what does the `?` in `email?: string` change — for code that builds the object, for code that reads the property, and for the emitted JavaScript?

## What `?` actually declares An object type is two contracts in one: what a *producer* must supply when it builds a value, and what a *consumer* may assume when it reads one. The `?` modifier relaxes both at the same time. ```ts interface User { id: number; email?: string; } ``` For the producer, the key may be missing: `const u: User = { id: 1 }` compiles, whereas dropping `id` produces *Property 'id' is missing in type '{}' but required in type 'User'*. For the consumer, the property type is no longer `string`. With `strictNullChecks` enabled, `u.email` has type `string | undefined`, because there may be nothing there to read. That widening is the entire payoff — the checker now forces the absent case to be handled at every read site: ```ts u.email.toLowerCase(); // error: possibly 'undefined' u.email?.toLowerCase(); // ok const e = u.email ?? 'none'; // ok, e: string ``` If `strictNullChecks` is off, the read type stays `string`, the guard is not required, and the same code that type-checks will throw at runtime on a missing key. Optional properties are only as useful as that flag. ## Optional is not the same as nullable `email?: string` says *the key may be absent*. `email: string | null` says *the key is always there and may hold `null`*. They are different runtime shapes and different obligations on the producer, and mixing them up is the most common beginner mistake here. A wire format that sends `"email": null` is modelled by the union; one that omits the field is modelled by `?`. ## Optional methods and `delete` The modifier is not restricted to data properties. A method member can be optional too, and calls to it must be guarded: ```ts interface Handler { onClose?(): void; } declare const h: Handler; h.onClose?.(); // ok — no call when it is absent ``` Optionality is also what unlocks `delete`. With `strictNullChecks` on, `delete u.id` is rejected with *The operand of a 'delete' operator must be optional*, because removing the key would leave a value that no longer matches its declared type. `delete u.email` is fine. ## Assignability follows the same rule Because a required property satisfies everything an optional one asks for, `{ id: number; email: string }` is assignable to `User`. The reverse is not: a `User` cannot be passed where `email` is required, since it may not have one. Optionality is a widening of the accepted set, not a cosmetic annotation. ## Nothing survives compilation An `interface` emits no JavaScript at all — declaration and modifiers alike vanish. `?` therefore adds no existence check, no default, and no cost. The practical consequence is that the guarantee only covers values the checker actually saw. A parsed JSON payload, an `any` from an untyped library, or a value produced by a type assertion can carry any shape whatsoever; the declaration is a claim about your code, not a validation of your data. If the shape must be trusted, validate at the boundary with real runtime code. Detecting the two runtime situations — key absent versus key present holding `undefined` — needs a runtime tool, not the type. The `in` operator and `Object.hasOwn` answer that question; a plain `u.email === undefined` cannot tell them apart: ```ts const a = { email: undefined }; const b = {} as { email?: string }; 'email' in a; // true 'email' in b; // false ``` ## The looseness worth knowing about By default `?` accepts more than "may be missing": you may also write the key explicitly with the value `undefined`, so `{ id: 1, email: undefined }` is a legal `User`. That deliberate blur — absent and present-undefined treated as the same thing — is what the `exactOptionalPropertyTypes` compiler option tightens. Under default settings, treat `?` as *may be missing or explicitly undefined*. ## How to answer in an interview Name all three surfaces without prompting: the producer may omit the key, the consumer reads `T | undefined` under `strictNullChecks`, and the emitted JavaScript is untouched. That last clause is what separates a candidate who has read the handbook from one who has only used the syntax.