`Hash` implementation for `Path` ignores path separators about rust HOT 4 CLOSED

Hash is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not Hash.

There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.

from rust.

I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like foo/./bar and foo/bar — why is foobar and foo/bar different? It seems like a very surprising collision for a user to encounter.

Thanks for taking a look!

from rust.

I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like foo/./bar and foo/bar — why is foobar and foo/bar different?

The difference is that Hash is a companion for Eq. If things compare equal then they must hash the same because that's what hashmaps rely on. foo/./bar and foo/bar do compare equally because Components normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that.

Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.

from rust.

That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.

from rust.