In TypeScript, why is an instance of `class Meters { constructor(private value: number) {} }` not assignable to `class Feet { constructor(private value: number) {} }`, even though the two classes have identical shapes?

## The rule TypeScript compares types structurally: two types are compatible when their members line up. Private and protected members are the deliberate exception. When comparing two types, the checker requires that a `private` or `protected` member on one side **originates from the same declaration** as the corresponding member on the other. Two independent classes, even character-for-character identical, have two different declarations, so they never match. ```ts class Meters { constructor(private readonly value: number) {} } class Feet { constructor(private readonly value: number) {} } declare function jump(height: Meters): void; jump(new Meters(3)); // jump(new Feet(3)); // error: the classes declare 'value' privately, separately ``` The compiler's diagnostic names exactly this: the types have separate declarations of a private property. ## Why the rule exists A private member is, by definition, not part of the type's public contract — outside code cannot read or write it. If it were compared structurally by name and type, then any class that happened to have a private field of the same name would be substitutable, which would silently defeat the encapsulation the modifier was asked to provide. Requiring declaration identity means "only things that actually inherit this implementation count". That is also why inheritance still works: ```ts class Kilometres extends Meters {} jump(new Kilometres(3)); // fine: inherits the same 'value' declaration ``` `Kilometres` did not redeclare `value`; it inherited it, so the declaration is shared and assignability holds. Redeclaring the member in the subclass would break it again. ## Using it deliberately: nominal emulation Because the rule is about declaration identity rather than about privacy being useful, you can exploit it. Adding a single private member to a class makes that class non-interchangeable with every lookalike, which is the class-based counterpart to a phantom brand on a primitive: ```ts class Currency { private readonly nominal!: void; constructor(readonly amount: number, readonly code: string) {} } ``` The `nominal` member exists only to make the type unique. Note the definite-assignment `!` — the field is never assigned, so the compiler needs to be told not to complain under strict initialization checking, and `void` is used because no value will ever be stored. ## The `#private` variant ECMAScript private fields written with `#` are a genuine runtime feature rather than a compile-time modifier, and they too make class types non-interchangeable: a class with `#value` is not assignable to a different class with `#value`, because the field is not a member the other type has. The difference is what happens at emit — a `private` modifier is erased and the property is an ordinary, fully accessible property in the emitted JavaScript, while `#value` is really inaccessible at runtime. For the assignability question they behave the same way; for actual encapsulation only `#` delivers. ## Compared with a phantom brand Both achieve nominality; they cost differently. | | Private-member class | Phantom brand on a primitive | |---|---|---| | Runtime cost | one object allocation per value | none, value stays a primitive | | Use sites | unwrap via a property or method | value used directly | | Encapsulation | real (with `#`), can carry behaviour | none, it is still a string | | Interop | must unwrap for JSON, map keys, logging | works everywhere a primitive works | So: brand a primitive when the value *is* a primitive and you only want the compiler to stop confusing two of them. Reach for a class with a private member when the value has behaviour, invariants worth hiding, or a genuine need for runtime encapsulation. ## Traps worth knowing - **Two classes generated from the same generic factory function share the declaration.** If the class is produced inside a function, every call returns a class whose members come from the same source declaration, so instances of different calls may still be mutually assignable. - **Interfaces cannot declare private members**, so this technique is class-only. An interface describing a class with private members can never be implemented by anything else, which is occasionally used to seal a type. - **The error message confuses readers.** "Types have separate declarations of a private property" reads like a bug report when it is in fact the feature working; a comment on the marker member saves the next reader a search.