Some standard libraries let a hash container carry its own equality: C++'s std::unordered_map takes Hash and KeyEqual template arguments, and .NET's Dictionary<TKey,TValue> accepts an IEqualityComparer<T> at construction. Others fix the relation on the key type — java.util.HashMap has no such hook, and Go's map always uses the language's == operator. Suppose you need one case-insensitive, Unicode-normalised index over strings while ordinary string equality stays exact everywhere else in the program. How do you build that on each side of the divide, and what is the design argument for the keying relation belonging to the container rather than to the type?

## Two questions that look like one Every hash container answers a question when you look something up: *is this probe key the same as that stored key?* Programmers usually assume the answer comes from the key type — from its `equals`, `__eq__`, `operator==`, or the language's built-in `==`. But the type answers a general question ("are these two things the same value?"), while a container answers a local one ("should these two things collide in this particular index?"). A single string type may simultaneously need an exact index, a case-insensitive index for usernames, and a Unicode-normalised index for filenames. Those are three relations over one type. Only one of them can be the type's own. That is why some standard libraries put a slot for the relation on the **container**, and it is the cleanest way to characterise how libraries differ here. ## Where the slot lives, language by language **C++ gives the container the slot outright.** `std::unordered_map<Key, T, Hash, KeyEqual, Allocator>` takes hashing and equality as template parameters; `std::map` takes a `Compare` and defines equivalence as `!(a < b) && !(b < a)`. Comparators may carry state and are passed at construction, so a locale-aware or normalising comparator is an ordinary object. Since C++20 (C++14 for the ordered containers), a comparator marked `is_transparent` also enables *heterogeneous lookup*: probing with a `string_view` without materialising a `string`. **.NET bundles the pair into one interface.** `Dictionary<TKey,TValue>` and `HashSet<T>` accept an `IEqualityComparer<T>`, which supplies both `Equals` and `GetHashCode`, at construction. `StringComparer.OrdinalIgnoreCase` is the everyday instance. Bundling is not cosmetic: it makes it structurally hard to supply an equality without the matching hash. **Rust gives you half the slot.** `HashMap<K, V, S = RandomState>` parameterises the *hasher* only; equality always comes from `K: Eq`. Swapping `S` changes distribution and hash-flooding resistance, never which keys are considered equal. A case-insensitive Rust index therefore needs a newtype wrapper implementing `PartialEq`/`Eq`/`Hash` over the folded form. **Java, Go, Python and Swift give the hash container no slot at all.** `HashMap` uses the key's own `hashCode`/`equals`; Go compares map keys with `==` on comparable types with no hook whatsoever; Python uses `__hash__`/`__eq__`; Swift requires `Hashable` on the type. Java's partial compensations are revealing: `TreeMap`/`TreeSet` *do* take a `Comparator` and key by `compare() == 0`, which the `SortedMap` contract openly documents as being inconsistent with `equals`; and `IdentityHashMap` had to ship as a **separate class** precisely because the relation could not be parameterised. ## Building the index on the no-slot side Two honest techniques, both of which move the relation off the general type: 1. **Canonicalise the key at the boundary.** Normalise to NFC, apply case folding once, store and probe with that canonical string. Cheap and portable; the cost is that the map no longer holds the original spelling, so keep it in the value if you need it back. 2. **Wrap the key in a dedicated type** — a `CaseInsensitiveKey` whose equality and hash are defined over the folded form. This puts the relation in the type system where a reader can see it, at the price of a wrapper allocation and conversion at every call site. What you must not do is redefine the string type's general equality, or push a looser `equals` onto your own domain type because one index wanted it. That makes every other comparison in the program lie. ## The invariants no slot exempts you from Whichever mechanism you pick, the relation must be an **equivalence relation** — reflexive, symmetric, transitive — and the hash must be **compatible**: if two keys are equal, they must hash equal. The classic self-inflicted bug is folding case in the equality function but hashing the raw string; equal keys then land in different buckets and lookups miss silently. Unicode makes this easy to get wrong: U+212A KELVIN SIGN folds to `k`, and full folding maps `ß` to `ss`, so an ad-hoc lowercase in one function and a different fold in the other quietly break compatibility. The relation must also stay **stable** while a key is stored — mutating a key already in a map is a logic error in every language named above. ## The trade the no-slot languages are making Container-owned relations are more expressive, but the behaviour of a lookup now depends on configuration supplied far from the call site — and that configuration is easy to lose. Copying a .NET dictionary with `new Dictionary<string,V>(existing)` uses the default comparer unless you pass one explicitly; `ToDictionary()` without a comparer argument does the same; and JSON round-tripping drops it entirely. A case-insensitive index silently becomes case-sensitive with no type error. Culture-sensitive comparers add a second hazard: under a Turkish locale, `I` folds to `ı`, so membership can differ by host. Prefer ordinal comparers for identifiers. Java and Go are buying the opposite property: one relation per type, globally checkable, impossible to lose in a copy. The cost is a wrapper type every time you need a second relation. Neither answer is wrong — but you should be able to say which regime you are in, and where your index's relation is written down.