Hashable documentation should be more clear about relationship with Equatable

[natecook1000]

The Hashable documentation should be more clear about the exact relationship of the Hashable and Equatable protocols. Specifically, the docs should make the expectation that all properties that are included in the == implementation are also included in hash(into:) and vice versa. It would be great if the docs could also discuss what happens if something like a struct property is left out of the Hashable/Equatable conformance implementations.

For the Set type, the docs should describe the requirement for the elements. That is, Hashable conformance is required and a type's Equatable is used to determine uniqueness within the set.

Links:

• https://developer.apple.com/documentation/swift/hashable
• https://developer.apple.com/documentation/swift/equatable
• https://developer.apple.com/documentation/swift/set

[tbkka]

It is a hard requirement that any property considered in the hash also be considered in the == test. Failure to do so can lead to cases where two items test equal but have different hash values. This results in inconsistent handling in Set, Dictionary, etc, in which items cannot be found after insertion or incorrectly override one another.

The converse is not a hard requirement, but is a useful rule-of-thumb that can help avoid obvious errors. However, there are cases where a field is expensive to hash where it makes sense to omit it from the hash but include it in == tests.

[lorentey]

The converse is not a hard requirement, but is a useful rule-of-thumb that can help avoid obvious errors. However, there are cases where a field is expensive to hash where it makes sense to omit it from the hash but include it in == tests.

I think there is a little more to this than that, and I believe it's worth pushing back on this a little.

Set and Dictionary (and Hashable/Hasher) work very hard to guarantee that they meet a reasonable set of performance expectations for all possible inputs, providing (hopefully!) good protection against HashDoS attacks.

These protections strongly rely on hash(into:) being precisely as strong as ==. Hashing must not omit any information that gets compared by the equality relation, or all this work is moot -- and attackers will be able to trivially induce hash collisions, re-opening the door to denial of service attacks.

Hashable conformances that omit certain "expensive" fields are, in a very real sense, broken. The breakage perhaps isn't as bad as UD can be, but I would not like to wake up one day to hear that a Hashable implementation I wrote was used as an amplifier for an attack that brought down a critical service, or one that rendered client devices unusable.

We need to stop recommending people to write exploitable code. Good hashing hygiene is part of this!