Borrow и AsRef оба позволяют преобразование ссылки в ссылку, но Borrow накладывает строгие контрактные гарантии на семантику равенства и хеширования. Когда тип реализует Borrow<T>, он обещает, что borrow() возвращает значение, которое сопоставимо равно (через Eq) и производит идентичные хеш-значения (через Hash) с исходным типом. AsRef не имеет этих ограничений; он просто позволяет дешевое преобразование, не требуя, чтобы преобразованный вид сохранял то же поведение хеширования или равенства. HashMap требует Borrow для своего метода get, потому что он должен гарантировать, что ключ, вставленный как String, может быть надежно извлечен с использованием &str, гарантируя, что оба типа соответствуют одному и тому же внутреннему бакету и сравниваются на равенство во время разрешения коллизий.
Вы разрабатываете высокопроизводительную таблицу маршрутизации для HTTP-прокси, где ключи маршрутов хранятся как принадлежащие String объекты, но входящие запросы предоставляют сегменты пути в виде &str срезов, разбираемых из сетевого буфера.
Вы оцениваете три стратегии реализации. Во-первых, вы можете нормализовать все ключи в String во время поиска, обеспечивая типовую однородность; это оказывается чрезмерно дорогим из-за аллокаций на каждый запрос. Во-вторых, вы рассматриваете возможность использования AsRef<str> в качестве привязки для поиска, позволяя как String, так и &str преобразовываться в &str; однако AsRef допускает реализации, при которых ссылочные данные могут использовать разные формы нормализации Unicode или кодировки, что приводит к тому, что "café" как String и "café" как &str будут хешироваться в разные бакеты и приведут к промахам кэша, несмотря на логическое равенство. В-третьих, вы принимаете Borrow<str>, который контрактно гарантирует, что String::borrow() и &str производят идентичные результаты Hash и Eq, обеспечивая последовательное индексирование бакетов.
Вы выбираете подход с Borrow, потому что он устраняет аллокации на каждую заявку, сохраняя требуемую для правильного разрешения маршрутов хеш-согласованность. Результатом является механизм поиска без копирования, который принимает &str из сети и правильно сопоставляет пре-вставленные маршруты String без семантического сдвига.
Почему использование AsRef<str> вместо Borrow<str> для поиска в HashMap приводит к тонким сбоям в извлечении?
Хотя AsRef<str> позволяет преобразовывать как String, так и &str в &str, он не предоставляет гарантии, что хеш преобразованной ссылки совпадает с хешом оригинального принадлежащего значения. HashMap использует хеш-значение для определения бакета хранения; если String и &str производят разные хеши для одного и того же логического содержимого (например, из-за различных внутренних представлений или нормализации), поиск будет производиться в неправильном бакете и вернет None, несмотря на существование ключа. Borrow предотвращает это, требуя, чтобы hash(x.borrow()) == hash(x) и x.borrow() == x, гарантируя, что разнородные типы всегда соответствуют идентичным местам хранения, когда логически равны.
Почему HashMap одновременно требует как Borrow, так и ограничения на трейты Eq/Hash, учитывая, что Borrow уже подразумевает семантику равенства?
Borrow устанавливает эквивалентность между принадлежащей и заимствованной репрезентациями, но Eq и Hash определяют фактические алгоритмы сравнения и хеширования. Borrow только гарантирует, что эти алгоритмы производят последовательные результаты через границу типов; он не реализует их. HashMap нуждается в Eq, чтобы разрешать коллизии внутри бакета, и в Hash, чтобы первоначально вычислить индекс бакета. Без Borrow карта не могла бы безопасно принимать &str для нахождения ключа String; без Eq и Hash она не могла бы проводить необходимые сравнения или вычислять хеш-значение вообще.
Чем Borrow отличается от Deref при проекции через умные указатели, и почему HashMap полагается на Borrow для строковых ключей, а не на приведение Deref?
Deref обеспечивает автоматическое приведение к целевому типу и подразумевает отношение ссылки, но не обязывает к согласованности хеширования или равенства между умным указателем и его целевым типом. Гипотетический умный указатель мог бы Deref к закешированному или преобразованному виду, который отличается от внутреннего представления, используемого для хеширования. Borrow явно требует, чтобы заимствованный вид сохранял идентичные семантики Hash и Eq с оригиналом. HashMap использует Borrow для String, потому что он должен гарантировать, что "key" (как String) и "key" (как &str) сталкиваются в одном бакете; одно лишь приведение Deref не имеет формальной гарантии, что String::deref() и &str разделяют один и тот же контракт реализации хеша, тогда как Borrow кодифицирует этот инвариант.