You need a value type that guarantees "start is never after end", and you write it with your language's boilerplate generator — a Java record, a Kotlin data class, a Scala case class, a C# record, a Python frozen @dataclass. Each of these also hands callers a way to produce a modified copy (copy(...), the C# with expression, dataclasses.replace). Before you trust such a type to hold that rule, which construction paths would you enumerate, and where do these languages genuinely diverge?

## An invariant is a property of paths, not of a type A *business invariant* is a rule that must hold for every instance that exists: "start is never after end", "the currency code is one of a known set", "the item list is never empty". You enforce it by checking it wherever an instance can come into existence, and then making the instance immutable so the checked state cannot be invalidated afterwards. That makes enforcement a mechanical question: **enumerate every path that can produce an instance, and confirm the check runs on each one.** A type with four construction paths and validation on three of them has no invariant — it has a convention. The trouble with generated value types — Java's `record`, Kotlin's `data class`, Scala's `case class`, C#'s `record`, Python's `@dataclass` — is that the generator adds paths. You wrote one constructor; the compiler may have added another, and the added one is the one a future maintainer will reach for. ## What the generator actually adds All of these features remove the same drudgery: a constructor, component-wise equality, a hash, a printable form, and — the part that matters here — a *derived-copy* operation that produces a new instance identical to an existing one except for the components you name. Kotlin and Scala spell it `copy(...)`; C# spells it `x with { ... }`; Python spells it `dataclasses.replace(x, ...)` (and, since 3.13, `copy.replace`). Java spells it nothing: records generate no copy operation at all. That copy operation is a second constructor under another name, and the languages implement it in two fundamentally different ways. ## Family 1 — route through the constructor: Kotlin, Scala, Python Kotlin's generated `copy()` is compiled as a call to the *primary constructor*, passing the unchanged components as defaults. Everything the primary constructor does — including `init { require(start <= end) }` — runs again on every copy. Scala behaves the same way: statements in a case-class body are part of its constructor, so a `require` re-runs on `copy`. Python's `dataclasses.replace()` calls `__init__`, therefore `__post_init__`, therefore your validation. The leak in this family is not validation but *visibility*. The classic hardening idiom is a private constructor plus a validating static factory, so that the only way in is through the factory. Kotlin generated `copy()` as public even when the primary constructor was private, letting callers route around the factory; Kotlin 2.0.20 added `@ConsistentCopyVisibility` (with `@ExposedCopyVisibility` as the explicit opt-out) to align the two, on the way to making alignment the default. Scala 2 had the same wart with the synthesized `apply` and `copy` of a case class whose constructor was private; Scala 3 tightened it. Python's `replace()` will also happily rebuild a frozen instance, and `object.__setattr__` bypasses `frozen=True` entirely. ## Family 2 — copy the fields: C# C# does not route `with` through any constructor whose body you can write. `x with { End = 0 }` is lowered to a call to the compiler-generated clone member, which invokes the record's copy constructor — a member-wise field copy — followed by assignment through the `init` accessors of the components you named. No constructor body executes. Imperative validation therefore protects the first instance and nothing derived from it. Two facts sharpen this. First, a *positional* record such as `record Range(int Start, int End)` has no canonical-constructor body in which to put a check at all: you may not declare a constructor duplicating the primary parameter list, so validation must live in a property initializer or an `init` accessor from the start. Writing the type in non-positional form with an explicit validating constructor does give you a body — and `with` still skips it. Second, you cannot close the copy path: the clone member the compiler emits is public and not user-declarable (C# even forbids declaring a member named `Clone` on a record), so making the copy constructor private does not hide `with`. That leaves the `init` accessor, which works for single-component checks and *fails for cross-component ones*. During a `with`, the clone starts with the old values and the named assignments happen in order, so a check in `Start`'s accessor compares the new `Start` against the **old** `End`. `original with { Start = 9, End = 20 }` can be rejected even though the final state is valid — and the mirror case lets an invalid intermediate through when the order runs the other way. The honest conclusion is that a two-field invariant cannot be enforced on all of a C# record's paths: validate where the value enters the domain, or drop the record for a class with a private constructor and named factories. ## Depth and rebinding Every language here gives you shallowness for free. Java records are final and their fields cannot even be written by reflection, but a component of array or mutable-collection type is stored as handed in and handed back out, so callers on both sides hold a live alias — copy defensively on the way in and on the way out. Python's `frozen=True` only overrides attribute assignment to raise; a `list` field stays fully mutable. "Immutable" in all of these languages means *this reference cannot be rebound*, never *this object graph cannot change*. ## The checklist Three questions. **Paths**: which constructors exist — the one you wrote, the generator's copy, and the one your serialization framework uses — and does the check run on every one? **Depth**: is any component an array, a mutable collection, or a reference to a mutable object? **Visibility**: if the invariant is enforced by a factory rather than a constructor, is there a public copy path around the factory? ## The call Where the generator cannot hold the rule, choose deliberately: weaken the invariant to something every generated path preserves (usually right for purely structural rules), or give up generation for a hand-written type with a private constructor and named factories (usually right when violating the rule has real business consequence). What is never acceptable is documenting the rule in a comment and trusting the copy path to be used politely — that path is exactly the one the next maintainer will reach for.