Borrow e AsRef consentono entrambi la conversione da riferimento a riferimento, ma Borrow impone rigorose garanzie contrattuali sulla semantica di uguaglianza e hashing. Quando un tipo implementa Borrow<T>, promette che borrow() restituisce un valore che confronta come uguale (attraverso Eq) e produce gli stessi valori di hash (attraverso Hash) del tipo originale. AsRef manca di questi vincoli; consente semplicemente una conversione economica senza richiedere che la vista convertita mantenga lo stesso comportamento di hash o uguaglianza. HashMap richiede Borrow per il suo metodo get perché deve garantire che una chiave inserita come String possa essere recuperata in modo affidabile utilizzando un &str, garantendo che entrambi i tipi mappino allo stesso bucket interno e confrontino ugualmente durante la risoluzione delle collisioni.
Stai progettando una tabella di routing ad alte prestazioni per un proxy HTTP, dove le chiavi di percorso sono memorizzate come oggetti String posseduti, ma le richieste in arrivo forniscono segmenti di percorso come frammenti &str analizzati dal buffer di rete.
Valuti tre strategie di implementazione. In primo luogo, potresti normalizzare tutte le chiavi in String durante la ricerca, garantendo uniformità di tipo; ciò si dimostra proibitivamente costoso a causa delle allocazioni per ogni richiesta. In secondo luogo, prendi in considerazione l'utilizzo di AsRef<str> come limite di ricerca, consentendo sia String che &str di essere convertiti in &str; tuttavia, AsRef consente implementazioni in cui i dati referenziati potrebbero utilizzare diverse forme di normalizzazione Unicode o codifiche, causando che "café" come String e "café" come &str vengano hashati in bucket diversi e producano cache misses nonostante l'uguaglianza logica. In terzo luogo, adotti Borrow<str>, che garantisce contrattualmente che String::borrow() e &str producano identici risultati di Hash e Eq, assicurando un indicizzazione coerente dei bucket.
Selezioni l'approccio Borrow perché elimina le allocazioni per richiesta mantenendo la coerenza dell'hash necessaria per una corretta risoluzione dei percorsi. Il risultato è un meccanismo di ricerca a zero copie che accetta &str dalla rete e associa correttamente i percorsi String pre-inseriti senza deriva semantica.
Perché l'uso di AsRef<str> invece di Borrow<str> per la ricerca in HashMap porta a sottili fallimenti di recupero?
Anche se AsRef<str> consente la conversione sia di String che di &str in &str, non fornisce alcuna garanzia che l'hash del riferimento convertito corrisponda all'hash del valore posseduto originale. HashMap utilizza il valore hash per determinare il bucket di archiviazione; se String e &str producono hash diversi per gli stessi contenuti logici (ad esempio, a causa di rappresentazioni interne o normalizzazioni diverse), la ricerca cercherebbe nel bucket sbagliato e restituirebbe None nonostante la chiave esista. Borrow previene questo richiedendo che hash(x.borrow()) == hash(x) e x.borrow() == x, garantendo che i tipi eterogenei mappino sempre a identiche posizioni di archiviazione quando logicamente uguali.
Perché HashMap richiede sia Borrow che i vincoli dei trait Eq/Hash simultaneamente, dato che Borrow implica già la semantica di uguaglianza?
Borrow stabilisce un'equivalenza tra le rappresentazioni possedute e quelle prese in prestito, ma Eq e Hash definiscono gli algoritmi reali di confronto e hashing. Borrow garantisce solo che questi algoritmi producano risultati coerenti attraverso il confine di tipo; non li implementa. HashMap ha bisogno di Eq per risolvere le collisioni all'interno di un bucket e di Hash per computare inizialmente l'indice del bucket. Senza Borrow, la mappa non potrebbe accettare in modo sicuro &str per trovare una chiave String; senza Eq e Hash, non potrebbe eseguire i confronti necessari o calcolare il valore hash.
In che modo Borrow differisce da Deref quando si proietta attraverso i puntatori intelligenti, e perché HashMap fa affidamento su Borrow per le chiavi String piuttosto che su coerzioni di Deref?
Deref fornisce coercizione automatica a un tipo di destinazione e implica una relazione di riferimento, ma non impone coerenza di hash o uguaglianza tra il puntatore intelligente e il suo obiettivo. Un ipotetico puntatore intelligente potrebbe Deref a una vista memorizzata o trasformata che differisce dalla rappresentazione interna utilizzata per l'hashing. Borrow richiede esplicitamente che la vista presa in prestito mantenga le identiche semantiche di Hash e Eq rispetto all'originale. HashMap utilizza Borrow per String perché deve assicurarsi che "key" (come String) e "key" (come &str) collidano nello stesso bucket; la coercione Deref da sola non ha la garanzia formale che String::deref() e &str condividano lo stesso contratto di implementazione dell'hash, mentre Borrow codifica questo invariante.