Borrow and AsRef both enable reference-to-reference conversion, but Borrow imposes strict contractual guarantees on equality and hashing semantics. When a type implements Borrow<T>, it promises that borrow() returns a value that compares equal (via Eq) and produces identical hash values (via Hash) to the original type. AsRef lacks these constraints; it merely permits cheap conversion without requiring that the converted view maintains the same hash or equality behavior. HashMap requires Borrow for its get method because it must ensure that a key inserted as a String can be reliably retrieved using a &str, guaranteeing that both types map to the same internal bucket and compare equal during collision resolution.
You are designing a high-performance routing table for an HTTP proxy where route keys are stored as owned String objects, but incoming requests provide path segments as &str slices parsed from the network buffer.
You evaluate three implementation strategies. First, you could normalize all keys to String during lookup, ensuring type uniformity; this proves prohibitively expensive due to allocations on every request. Second, you consider using AsRef<str> as the lookup bound, allowing both String and &str to be converted to &str; however, AsRef permits implementations where the referenced data might use different Unicode normalization forms or encodings, causing "café" as String and "café" as &str to hash to different buckets and yield cache misses despite logical equality. Third, you adopt Borrow<str>, which contractually guarantees that String::borrow() and &str produce identical Hash and Eq results, ensuring consistent bucket indexing.
You select the Borrow approach because it eliminates per-request allocations while preserving the hash consistency required for correct route resolution. The result is a zero-copy lookup mechanism that accepts &str from the network and correctly matches pre-inserted String routes without semantic drift.
Why does using AsRef<str> instead of Borrow<str> for HashMap lookup lead to subtle retrieval failures?
While AsRef<str> allows converting both String and &str to &str, it provides no guarantee that the hash of the converted reference matches the hash of the original owned value. HashMap uses the hash value to determine the storage bucket; if String and &str produced different hashes for the same logical content (for example, due to different internal representations or normalization), the lookup would search the wrong bucket and return None despite the key existing. Borrow prevents this by requiring that hash(x.borrow()) == hash(x) and x.borrow() == x, ensuring that heterogeneous types always map to identical storage locations when logically equal.
Why does HashMap require both Borrow and Eq/Hash trait bounds simultaneously, given that Borrow already implies equality semantics?
Borrow establishes equivalence between the owned and borrowed representations, but Eq and Hash define the actual comparison and hashing algorithms. Borrow only guarantees that these algorithms produce consistent results across the type boundary; it does not implement them. The HashMap needs Eq to resolve collisions within a bucket and Hash to compute the bucket index initially. Without Borrow, the map could not safely accept &str to find a String key; without Eq and Hash, it could not perform the necessary comparisons or compute the hash value at all.
How does Borrow differ from Deref when projecting through smart pointers, and why does HashMap rely on Borrow for String keys rather than Deref coercion?
Deref provides automatic coercion to a target type and implies a reference relationship, but it does not mandate hash or equality consistency between the smart pointer and its target. A hypothetical smart pointer could Deref to a cached or transformed view that differs from the internal representation used for hashing. Borrow explicitly requires that the borrowed view maintains identical Hash and Eq semantics to the original. HashMap uses Borrow for String because it must ensure that "key" (as String) and "key" (as &str) collide in the same bucket; Deref coercion alone lacks the formal guarantee that String::deref() and &str share the same hash implementation contract, whereas Borrow codifies this invariant.