When implementing PartialEq and Hash for a struct containing a raw pointer, assuming I want pointer equality semantics, I can use std::ptr::eq and std::ptr::hash functions.
When the struct holds an Arc I can use Arc::ptr_eq for PartialEq.
Shouldn't there be a function Arc::ptr_hash?
Currently I use Arc::as_ptr(self.field).hash(&mut hasher) (this might be incorrect for fat pointers?), but having Arc::ptr_hash would be superior in following ways
hash and equals must be consistent. When equals uses Arc::ptr_eq the user should not need to guess what's the consistent hash function to be used. Using Arc::ptr_hash would be "obviously correct".
API consistency
when using PartialEq, Hash derivation helper like crates.io: Rust Package Registry, I can delegate particular field comparison/hash to a named function (like Arc::ptr_eq), but I cannot delegate to "an expression" (like Arc::as_ptr(self.field).hash(&mut hasher)). Thus adding ptr_hash would make Arc possible to use with derivative's features
If it makes sense to add Arc::ptr_hash, should I create an issue?
ptr_hash is not always consistent with PartialEq. Once the Arc gets deallocated, a new Arc can be allocated at the same location with a different PartialEq value. ptr_eq doesn't have this problem as it guarantees that both Arc are currently alive. Also ptr_hash may result in accidental non-determinism or leaking the ASLR seed.
ptr_eq doesn't have this problem as it guarantees that both Arc are currently alive
I think it's not a problem for hash function.
Hash functions may (and will) have collisions sometimes.
Returning same hash value for an Arc that was earlier returned as a hash value for another Arc should be fine.
A "constant 42" hash function is a valid hash function, just not very useful.
Also ptr_hash may result in accidental non-determinism or leaking the ASLR seed.
I don't understand this part. Would you mind explaining a bit more for me?
Perhaps per analogy how this is different from std::ptr::hash, which I believe compares full fat pointers, but otherwise feels similar.
ptr::hash also may leak the ASLR seed. If you get the hash output, you can brute-force it back to the original pointer. You only got like 45 bits of entropy max (48bits for x86_64 pointers without 5 level page tables - 3 bits for minimum 8 byte alignment of the Arc allocation) with less in practice. But I guess this is a pre-existing issue, not something to block ptr_hash on.
How is leaking via the hash any more of a problem than leaking via the actual pointer value itself? Neither should be exposed to untrusted parties obviously.