Two strings hold identical characters — why can an identity comparison still report them as different?

## Two different questions | Comparison | The question it answers | Cost | |---|---|---| | Identity | Do these two references denote **one object**? | O(1), one reference comparison | | Content equality | Do these two objects hold the **same characters**? | O(n) worst case; short-circuits on length, and on a cached hash mismatch | The two answers coincide in one direction only. **Identical implies equal** — one object trivially has the same characters as itself. **Equal does not imply identical** — two separately allocated strings may hold exactly the same characters and remain two objects. Immutability does not change this. Immutability guarantees the characters of a value cannot drift; it makes no promise that the system stores each distinct value exactly once. Storing each distinct value once is a *separate* mechanism — canonicalization, also called interning — and it applies only to the values you actually route through the canonical table. ## Where the extra objects come from ``` a = "service-alpha" // fixed in the program text b = concat("service-", "alpha") // assembled at run time c = a // a second name for one object ``` `a` and `c` are one object; identity is true. `b` holds thirteen identical characters but was allocated by a run-time operation, so identity against `a` is false while content equality is true. Every source of run-time strings behaves like `b`: characters decoded from a socket or a file, a slice taken out of a larger buffer, the result of trimming or lowercasing, a value deserialized from a request body, a key rebuilt from two fields. Fixed literals in the program text are the *exception* that gets canonicalized, not the rule. ## Why the bug survives testing This is the trap the question exists to set. In a unit test you write the expected value as a literal and often construct the input as a literal too. Both sides are canonicalized to one shared object, identity returns true, and the test passes. In production one side arrives over the wire and identity returns false — for values that are, character for character, equal. Worse, this often only breaks *partly*: the values that happen to have gone through a deduplication cache still compare identical, so the failure is intermittent and correlates with cache warmth, which is about the most expensive shape a bug can have. The right lesson is not "identity comparison is flaky"; it is that identity was answering a different question all along and happened to give the answer you wanted on your sample. Mainstream ecosystems differ enough here to make the point vividly: Java and C# automatically canonicalize compile-time string literals so identity often succeeds on them, Python canonicalizes short identifier-like strings by an unspecified rule that has changed between versions, and Go performs no such canonicalization at all. Any code whose correctness depends on which of those rules is in force is depending on an implementation detail. ## When identity is legitimate Identity comparison of strings is a valid and genuinely fast optimisation under one condition: **every value being compared, on both sides, is guaranteed to have come from the same canonicalization table.** That is achievable in a closed system — a parser that maps every token to a canonical instance on the way in, an event pipeline that canonicalizes the field it later groups by — and it is worth real money when the comparison sits in a hot loop, because you trade an O(n) character walk for one reference comparison. It is unachievable, and therefore a bug, whenever an un-canonicalized value can reach the comparison from any path: a new caller, a new deserialization route, a cached value that expired. The discipline that keeps this safe is to make the canonicalization the *only* constructor for that type of value — wrap the canonical instance in its own type, so a raw string cannot be passed where a canonical one is expected. If you cannot enforce that, compare contents. ## A useful pattern from inside content comparison A well-implemented content comparison usually starts with an identity check as a fast path: if the two references are the same object, return true immediately without touching a single character. That is identity used *correctly* — as an optimisation inside an operation whose contract is content equality, where a false answer costs nothing but a character walk. Contrast that with identity used *as* the equality test, where a false answer is simply wrong. The difference between those two uses is what an interviewer is really probing.