Explain how 'singleton constants' for enums versus 'closed set of subtypes' for sealed types affects instance count, identity, and exhaustiveness guarantees the compiler can give.

## Instance count ### Enum: fixed singletons Every enum entry is a single shared instance created once when the enum class loads. `Suit.HEARTS` is the *same object* everywhere. You can never have two `Suit.HEARTS`. This guarantees: - **Identity equality:** `a === b` is true iff they're the same entry; `==` and `===` agree. - **Cheap collections:** `EnumSet`/`EnumMap` use the entries' `ordinal` to back themselves with bit-vectors/arrays — far faster and smaller than hash-based sets/maps. - **Stable `ordinal`/`name`:** each entry has a fixed position and name. ### Sealed: closed subtypes, open instances `sealed` closes the *set of direct subtypes*, not the instance count. A sealed subtype that's an `object` is a singleton (like an enum entry); a subtype that's a `class`/`data class` can be instantiated **any number of times**: ```kotlin sealed interface Expr data class Num(val v: Int) : Expr // many: Num(1), Num(2), ... data class Add(val l: Expr, val r: Expr) : Expr data object Zero : Expr // one instance ``` So `Num(1)` and `Num(2)` are distinct objects; equality is **structural** (data class), not identity. ## Identity and equality - Enum: identity == structural (singletons). Safe to use `===`. - Sealed `object`/`data object` cases: singletons too, so identity works. - Sealed `data class` cases: equality is value-based; two equal-valued instances are `==` but not `===`. Never rely on `===` for these. ## Exhaustiveness — why the compiler can prove it A `when` used as an **expression** must be exhaustive (and since Kotlin 1.7, exhaustiveness is also enforced for `when` **statements** over sealed/enum subjects). The compiler proves coverage because the candidate set is *closed and known*: - **Enum:** it knows the full list of entries. - **Sealed:** `sealed` forbids subtypes outside the same module (same package for sealed classes), so the compiler can see *all* direct subtypes and require a branch for each. ```kotlin fun eval(e: Expr): Int = when (e) { // no else needed is Num -> e.v is Add -> eval(e.l) + eval(e.r) Zero -> 0 } ``` Add a new subtype `Mul` and this `when` stops compiling until you handle it — the compiler turns 'I forgot a case' into a build error. The same happens when you add an enum entry to an exhaustive `when`. ## Why it matters in design - Need identity, ordinal ordering, fast set/map keys, name-based serialization => the singleton nature of **enums** is a feature. - Need many instances each carrying different data, recursive structures (ASTs), or per-case payloads => **sealed**, accepting structural equality and no built-in ordinal. - Both give the safety net of compiler-checked exhaustiveness; that's the shared reason to model closed sets with either. ## Pitfall Don't assume `===` works on sealed data-class cases — it compares references, so two structurally-equal `Num(1)` values are not `===`. And don't expect a sealed subtype to be a singleton just because the enum it replaced was — only `object`/`data object` cases are.