Is the implementation of Borrow reasonable

[A4-Tacks]

The behavior that needs to be guaranteed for equivalent instances is described in the document of std::hash::Hasher

This trait provides no guarantees about how the various write_* methods are
defined and implementations of [Hash] should not assume that they work one
way or another. You cannot assume, for example, that a [write_u32] call is
equivalent to four calls of [write_u8]. Nor can you assume that adjacent
write calls are merged, so it's possible, for example, that

# fn foo(hasher: &mut impl std::hash::Hasher) {
hasher.write(&[1, 2]);
hasher.write(&[3, 4, 5, 6]);
# }

and

# fn foo(hasher: &mut impl std::hash::Hasher) {
hasher.write(&[1, 2, 3, 4]);
hasher.write(&[5, 6]);
# }

end up producing different hashes.

Thus to produce the same hash value, [Hash] implementations must ensure
for equivalent items that exactly the same sequence of calls is made -- the
same methods with the same parameters in the same order.

Although CachedHash implements Borrow<T>, its hash behavior attempts to equate write_u64 with unknown write calls

This does not match the description in Borrow document

In particular Eq, Ord and Hash must be equivalent for
borrowed and owned values: x.borrow() == y.borrow() should give the
same result as x == y.

cachedhash/src/cachedhash.rs

Lines 169 to 182 in 28fafd6

	impl<T: Eq + Hash, BH: BuildHasher> Hash for CachedHash<T, BH> {
	fn hash<H2: Hasher>(&self, state: &mut H2) {
	if let Some(hash) = self.hash.get_raw() {
	state.write_u64(hash);
	} else {
	let mut hasher = self.build_hasher.build_hasher();
	self.value.hash(&mut hasher);
	// AtomicOptionNonZeroU64 can only store non-zero values so we create a small collision by bumping up hash 0 to 1.
	let hash = NonZeroU64::new(hasher.finish()).unwrap_or(NonZeroU64::new(1).unwrap());
	self.hash.set(Some(hash));
	state.write_u64(hash.into());
	}
	}
	}

cachedhash/src/cachedhash.rs

Lines 202 to 206 in 28fafd6

	impl<T: Eq + Hash, BH: BuildHasher> Borrow<T> for CachedHash<T, BH> {
	fn borrow(&self) -> &T {
	Self::get(self)
	}
	}

[A4-Tacks]

Sorry, I seem to have misunderstood. I don't need to guarantee the relationship between x == x.borrow()

[A4-Tacks]

This is mentioned later in the Borrow document, require hash(&k) == hash(k.borrow())

The entire hash map is generic over a key type K. Because these keys
are stored with the hash map, this type has to own the key’s data.
When inserting a key-value pair, the map is given such a K and needs
to find the correct hash bucket and check if the key is already present
based on that K. It therefore requires K: Hash + Eq.

When searching for a value in the map, however, having to provide a
reference to a K as the key to search for would require to always
create such an owned value. For string keys, this would mean a String
value needs to be created just for the search for cases where only a
str is available.

Instead, the get method is generic over the type of the underlying key
data, called Q in the method signature above. It states that K
borrows as a Q by requiring that K: Borrow<Q>. By additionally
requiring Q: Hash + Eq, it signals the requirement that K and Q
have implementations of the Hash and Eq traits that produce identical
results.

The implementation of get relies in particular on identical
implementations of Hash by determining the key’s hash bucket by calling
Hash::hash on the Q value even though it inserted the key based on
the hash value calculated from the K value.

As a consequence, the hash map breaks if a K wrapping a Q value
produces a different hash than Q. For instance, imagine you have a
type that wraps a string but compares ASCII letters ignoring their case:

failed example

use cachedhash::CachedHash;
use std::collections::HashSet;

fn main() {
    let s = "foo";
    let cached = CachedHash::new(s);
    let mut set = HashSet::new();
    set.insert(cached.clone());
    assert!(set.contains(&cached)); // passed
    assert!(set.contains(&s)); // panic
}