Given `enum Priority { Low = 1, High = 2 }` in TypeScript, does `const p: Priority = value` compile when `value` is typed `number`, and what does the answer mean for enum-typed data that arrived as JSON?

## What actually compiles Start from the observed behaviour, checked against TypeScript 6.0: ```ts enum Priority { Low = 1, High = 2 } const a: Priority = 3; // Error: Type '3' is not assignable to type 'Priority' const b: Priority = 1; // fine — matches Priority.Low declare const n: number; const c: Priority = n; // NO ERROR — any number-typed value is accepted function schedule(p: Priority) { /* ... */ } schedule(3); // Error: Argument of type '3' is not assignable schedule(n); // NO ERROR ``` So the checker knows the enum's type is the union of its member types — that is why the literal `3` is rejected. But it keeps a special assignability rule that lets the wide type `number` flow into a numeric enum type. Once the value is a `number` rather than a literal, the check evaporates. ## Why the hole exists Numeric enums were designed to model the JavaScript and C-style idiom of integer constants, including bit-flag usage where you legitimately compute values (`Flags.A | Flags.B`) that are not themselves declared members. Rejecting all `number` values would break that idiom, so the language accepts the wide type. The result is the most-cited unsoundness of TypeScript's basic types: a `Priority`-annotated variable does not guarantee its value is `1` or `2`. An annotation is a *claim about* a value, never a check *of* a value — types are erased, so there is no runtime gate anywhere in the emitted code. Every TypeScript unsoundness has this same root, and numeric enums are the version of it you meet earliest. ## Where it bites in production External data is the danger zone, because that is where `number` comes from: ```ts type Payload = { priority: number }; declare const payload: Payload; schedule(payload.priority); // compiles; payload.priority might be 7 ``` A `payload.priority` of `7` now travels through the system carrying the type `Priority`. Two failures follow: **Silent fall-through.** A `switch` written over the declared members handles `Low` and `High`, hits neither, and falls off the end. If the function's return type is not annotated, the checker may even accept the resulting `undefined` path without complaint. **A lie in the reverse lookup.** For `enum Priority { Low = 1, High = 2 }`, the emitted object maps both directions, so `Priority[p]` is typed `string`. At runtime `Priority[7]` is `undefined`, and the very next `.toUpperCase()` throws — a `TypeError` on an expression the compiler assured you was a string. The same class of bug arrives through a cast. `const p = payload.priority as Priority` compiles by definition: an assertion silences the checker without inspecting anything. ## The actual fix Validate where untyped data enters, once, and never again: ```ts enum Priority { Low = 1, High = 2 } function toPriority(value: unknown): Priority { if (value === Priority.Low || value === Priority.High) return value; throw new Error(`Unknown priority: ${String(value)}`); } ``` The check is ordinary runtime code, and it is the only thing that makes the annotation true. A schema-validation library does the same job at scale. The important habit is that the boundary function returns the narrow type and everything inside the system can then trust it. ## How the alternatives compare A union of string literals does not share the hole: ```ts type Status = 'active' | 'archived'; declare const raw: string; const s: Status = raw; // Error: Type 'string' is not assignable to type 'Status' ``` There is no rule letting the wide `string` into a literal union, so the compiler forces you to narrow — usually by writing exactly the runtime check you needed anyway. That asymmetry is one of the strongest technical arguments for preferring string-literal unions over numeric enums, quite apart from bundle size. String enums are also stricter than numeric ones here: a `string`-typed value is rejected. But they remain assertion-bypassable like everything else, so boundary validation is still your job. ## What a strong answer sounds like State the behaviour precisely — literal rejected, `number` accepted — attribute it to the wide-type assignability rule rather than to a bug, then move immediately to the consequence for external data and the boundary-validation fix. Finishing with the contrast against string-literal unions shows you understand this as a modelling choice, not trivia.