You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are hidden assumptions around Borrow that don’t appear to be included in any of the documentation that I can find. Most notably, HashMap’s use of Borrow requires that K and Q (where K: Borrow<Q>) hash the same; if they don’t, your HashMap will be mysteriously broken when you try indexing it by Q.
I’d suggest making Borrow an unsafe trait, but unsafe doesn’t mean blah blah mumble mumble memory safety mumble 😛
Anyway, we need some serious warnings on at least the Borrow documentation. Something including things like “if you are implementing Borrow and both Self and Borrowed implement Hash, they must produce the same result, for HashMap’s sake.”
The text was updated successfully, but these errors were encountered:
We can see how they’re kind of the same: they both deal with owned and borrowed versions of some type. However, they’re a bit different.
Choose Borrow when you want to abstract over different kinds of borrowing, or when you’re building a datastructure that treats owned and borrowed values in equivalent ways, such as hashing and comparison.
There are hidden assumptions around
Borrow
that don’t appear to be included in any of the documentation that I can find. Most notably,HashMap
’s use ofBorrow
requires thatK
andQ
(where K: Borrow<Q>
) hash the same; if they don’t, yourHashMap
will be mysteriously broken when you try indexing it byQ
.I’d suggest making
Borrow
an unsafe trait, but unsafe doesn’t mean blah blah mumble mumble memory safety mumble 😛Anyway, we need some serious warnings on at least the
Borrow
documentation. Something including things like “if you are implementingBorrow
and bothSelf
andBorrowed
implementHash
, they must produce the same result, for HashMap’s sake.”The text was updated successfully, but these errors were encountered: