Equality & Hashing Contract

## What generated equality actually promises A generated equality implementation derives "are these two instances the same value?" mechanically from a list of members, and derives the hash from the same list. That mechanical link is the real benefit: the two operations cannot drift apart, because one declaration produces both, so the law *equal objects must hash alike* is upheld by construction. What generation does **not** promise is that any two languages pick the same member list, the same subtype policy, or the same per-member comparison. Those three choices are where portable-looking value types stop behaving the same across a polyglot codebase. ## Axis 1 — which members are in the list Kotlin data classes take the properties of the **primary constructor only**. A property declared in the class body is not part of equality, hashing, `toString` or `copy`. This is deliberate — the constructor list *is* the value's identity — but it is the single most common surprise: someone moves a field into the body to give it a default or a custom getter, and two objects that differ in that field silently become equal. Because hashing is derived from the same list, the two also hash alike, so nothing ever throws. The bug is a wrong answer, never an exception. Scala case classes take the **first parameter list**; a second (curried or implicit) parameter list is excluded, with the same silent consequence. C# records take **all instance fields**, including the backing fields of stored properties declared in the body — a strictly more inclusive policy than Kotlin's. The same refactor that changes meaning in Kotlin changes nothing in C#. (A computed, backing-field-less property is not stored state and so is invisible everywhere.) Java records take exactly the record components, and the language forbids additional instance fields, so the list cannot drift — the refactor is not merely a no-op, it does not compile. So one refactor — "move this member out of the constructor list" — is a semantic change in two of these four languages, a no-op in the third, and rejected by the fourth. ## Axis 2 — what happens across a subtype boundary Extending a type that defines value equality is the classic trap: a lenient check breaks symmetry (base considers itself equal to a derived instance, the derived instance disagrees), while an exact-runtime-type check preserves symmetry at the cost of substitutability. The four generators take four different exits. - **Java records** and **Kotlin data classes** are final — a data class cannot be declared open — so the language removes the problem by removing the extension point. - **Scala** generates `canEqual`, a member that each side calls on the other. Both operands must agree to be compared, so a refining subtype that adds state can override `canEqual` and remain symmetric; the language ships the standard hand-written workaround as generated code. Inheriting one case class from another is prohibited precisely because the generated members would no longer compose. - **C# records** generate a virtual equality-contract property returning the runtime type, and generated equality compares contracts first. Two records of different runtime types are therefore never equal in either direction: symmetry and transitivity hold by construction, at the cost that a derived record can never equal a base record even when every field matches. C# also generates a virtual clone so that `with`-expressions through a base-typed reference preserve the derived type. The Kotlin leak here is subtler than "data classes are final": a data class *may* inherit from an open class, and the generated equality still looks only at its own constructor properties. Inherited state is invisible to equality and hashing, and the generated copy reconstructs the object through the primary constructor, dropping whatever the base initialised differently. ## Axis 3 — how each member is compared Every generator compares a member by delegating to that member's own equality. For reference-typed members whose own equality is identity — arrays being the universal example — the generated "value equality" degenerates into identity equality for that field. Two instances holding element-wise identical arrays are unequal, and a hash lookup with equal contents misses. All four share this trap; none deep-compares. Floating-point members are the mirror image. Generated equality typically routes through a total-order comparison rather than the primitive IEEE-754 operator, so a not-a-number member can compare equal to itself inside a generated value type while the raw comparison operator says otherwise — and the languages do not even agree with each other about negative zero. Do not assume the generated implementation and a hand-written field-by-field comparison agree on these members. Mutability is the last gap. Generation freezes nothing: a Kotlin data class may declare mutable properties, and a mutable member of any of these types stays mutable. Generation gives you the *contract*; it does not give you the immutability that makes the contract safe to rely on inside a hashed container, where a member mutated after insertion moves the key's hash and strands the entry. ## How to use this Treat generation as a good default with three review questions: is every field that defines the value actually in the generated list; is the type final or does the language have a subtype story; and does any member compare by identity where you meant by content. The three questions are language-independent even though every answer is language-specific.