Structural vs Nominal Typing: Workarounds

The plain-language idea

The branded types lesson showed the basic trick: attach a fake __brand field to a type so two otherwise-identical shapes stop being interchangeable. That's the entry-level version of a bigger idea. TypeScript actually gives you three distinct ways to opt a type out of structural comparison, and they don't all behave the same way once real code starts using them.

A plain string-literal brand ({ __brand: "UserId" }) is cheap but has a subtle weak spot: it's still just a property with a string value in type space. If two unrelated libraries both decide to brand their id types with the literal string "UserId", TypeScript sees the same shape and happily considers them compatible again — the exact bug branding was supposed to prevent, just one level up. unique symbol and private class fields close that gap in different ways.

See it in a real thing: three brands, three guarantees

// 1. String-literal brand — cheap, but collides if two modules pick the same literal
type UserId = string & { readonly __brand: "UserId" };

// 2. unique symbol brand — collision-proof, because the symbol value itself
//    can only come from this exact declaration, never from a matching string
declare const userIdBrand: unique symbol;
type SafeUserId = string & { readonly [userIdBrand]: true };

function makeSafeUserId(raw: string): SafeUserId {
  return raw as SafeUserId;
}

// 3. Private class fields — TypeScript compares classes nominally the moment
//    they have a private or protected member, no manual brand needed at all
class Meters {
  #value: number;
  constructor(value: number) { this.#value = value; }
  valueOf(): number { return this.#value; }
}

class Seconds {
  #value: number;
  constructor(value: number) { this.#value = value; }
  valueOf(): number { return this.#value; }
}

function addMeters(a: Meters, b: Meters): number {
  return a.valueOf() + b.valueOf();
}

declare const s: Seconds;
addMeters(s, s); // ❌ error — Seconds and Meters are structurally identical
                  // but each #value is a *different* private field identity

Meters and Seconds have the exact same public shape, yet TypeScript rejects the mix-up without a single __brand anywhere. Once a class declares a private (or protected) member, TypeScript stops comparing classes by shape and starts comparing them by the actual declaration identity of that private member — two #value fields from two different class bodies are never considered the same field, even if the surrounding code looks identical.

What people usually miss

Watch out

• A string-literal brand isn't actually airtight. It's a real, common-enough footgun that two independently-brande­d types with the same literal tag can silently interoperate again — unique symbol exists specifically to close this hole, because a symbol can't be recreated from a string.
• Private fields brand a class "for free," with no __brand property at all — but only once the class has at least one private or protected member. A class with only public fields is still fully structural, brand or no brand.
• None of these three techniques do anything at runtime. A unique symbol brand is erased like any other type-only construct; a private class field is real (JavaScript private fields do exist at runtime, enforced by the engine) but it's providing runtime encapsulation, not the type-level nominal check — those are two different guarantees that happen to come from the same feature.

Why this matters in interviews

"You've branded a type with a string literal — can you think of a way that could still fail?" is a strong follow-up to the basic branding question, and it separates candidates who memorized the __brand pattern from ones who understand why it works and where its guarantee actually ends.