Borrow et AsRef permettent tous deux la conversion de référence à référence, mais Borrow impose des garanties contractuelles strictes sur les sémantiques d'égalité et de hachage. Lorsqu'un type implémente Borrow<T>, il promet que borrow() renvoie une valeur qui est égale (via Eq) et produit des valeurs de hachage identiques (via Hash) au type original. AsRef manque de ces contraintes ; il permet simplement une conversion bon marché sans exiger que la vue convertie maintienne le même comportement de hachage ou d'égalité. HashMap exige Borrow pour sa méthode get car il doit garantir qu'une clé insérée comme String puisse être récupérée de manière fiable en utilisant un &str, garantissant que les deux types correspondent au même compartiment interne et soient égaux lors de la résolution des collisions.
Vous concevez une table de routage haute performance pour un proxy HTTP où les clés de route sont stockées sous forme d'objets String possédés, mais les requêtes entrantes fournissent des segments de chemin sous forme de tranches de &str analysées à partir du tampon réseau.
Vous évaluez trois stratégies d'implémentation. Premièrement, vous pourriez normaliser toutes les clés en String lors de la recherche, assurant l'uniformité des types ; cela s'avère prohibitif en raison des allocations à chaque requête. Deuxièmement, vous envisagez d'utiliser AsRef<str> comme limite de recherche, permettant à la fois à String et &str d'être convertis en &str ; cependant, AsRef permet des implémentations où les données référencées pourraient utiliser différentes formes de normalisation Unicode ou encodages, ce qui amène "café" en tant que String et "café" en tant que &str à hacher vers différents compartiments et à provoquer des échecs de cache malgré l'égalité logique. Troisièmement, vous adoptez Borrow<str>, qui garantit contractuellement que String::borrow() et &str produisent des résultats identiques pour Hash et Eq, assurant un indexage cohérent des compartiments.
Vous choisissez l'approche Borrow car elle élimine les allocations par requête tout en préservant la cohérence du hachage requise pour une résolution correcte des routes. Le résultat est un mécanisme de recherche sans copie qui accepte &str du réseau et correspond correctement aux routes String pré-insertées sans dérive sémantique.
Pourquoi utiliser AsRef<str> au lieu de Borrow<str> pour la recherche dans HashMap conduit-il à des échecs subtils de récupération ?
Bien que AsRef<str> permette de convertir à la fois String et &str en &str, il ne fournit aucune garantie que le hachage de la référence convertie corresponde au hachage de la valeur possédée d'origine. HashMap utilise la valeur de hachage pour déterminer le compartiment de stockage ; si String et &str produisent des hachages différents pour le même contenu logique (par exemple, en raison de différentes représentations internes ou normalisations), la recherche dans le compartiment erroné entraînerait un retour de None malgré l'existence de la clé. Borrow empêche cela en exigeant que hash(x.borrow()) == hash(x) et x.borrow() == x, garantissant que des types hétérogènes mappent toujours aux mêmes emplacements de stockage lorsque logiquement égaux.
Pourquoi HashMap exige-t-il à la fois des contraintes de Borrow et de traits Eq/Hash simultanément, étant donné que Borrow implique déjà des sémantiques d'égalité ?
Borrow établit l'équivalence entre les représentations possédées et empruntées, mais Eq et Hash définissent les algorithmes réels de comparaison et de hachage. Borrow ne garantit que ces algorithmes produisent des résultats cohérents à travers la frontière des types ; il ne les implémente pas. La HashMap a besoin de Eq pour résoudre les collisions au sein d'un compartiment et de Hash pour calculer initialement l'index du compartiment. Sans Borrow, la carte ne pourrait pas accepter en toute sécurité &str pour trouver une clé String ; sans Eq et Hash, elle ne pourrait pas effectuer les comparaisons nécessaires ni même calculer la valeur de hachage.
Comment Borrow diffère-t-il de Deref lorsqu'il projette à travers des pointeurs intelligents, et pourquoi HashMap s'appuie-t-il sur Borrow pour les clés String plutôt que sur la coercition Deref ?
Deref fournit une coercition automatique vers un type cible et implique une relation de référence, mais n'impose pas de cohérence de hachage ou d'égalité entre le pointeur intelligent et son cible. Un pointeur intelligent hypothétique pourrait Deref vers une vue mise en cache ou transformée qui diffère de la représentation interne utilisée pour le hachage. Borrow exige explicitement que la vue empruntée maintienne les mêmes sémantiques de Hash et Eq que l'original. HashMap utilise Borrow pour String car il doit garantir que "key" (en tant que String) et "key" (en tant que &str) se heurtent dans le même compartiment ; la seule coercition Deref manque de la garantie formelle que String::deref() et &str partagent le même contrat d'implémentation de hachage, tandis que Borrow codifie cette invariant.