As Carl notes in the comments, the move to the hashWithSalt
method over just hash
(as the original Hashable
used) was to allow people to mitigate DOS attacks based on hash collisions. For a period, a different random default salt was generated on every run, even, using unsafePerformIO
in the background. This lack of reproducibility turned out to be a huge problem, however, for people interested in e.g. persisting data structures across runs, getting reliable benchmarking numbers, etc.
So, the current approach is to provide the method, but tend to defer to a default salt that is fixed, and then add a warning to the documentation that this remains susceptible to various potential DOS attack vectors if used in a public-facing ways. (You can see for yourself in the documentation here: http://hackage.haskell.org/package/hashable-1.2.1.0/docs/Data-Hashable.html)
Because hash
is its own class method, it is easy enough to implement an object with a "saltless" hash that is memoed with it, and furthermore, you can implement hashWithSalt
as just xor
ing with the salt if you like. Or, as the comments note, you can implement hashWithSalt
via a more legitimate method of hash
ing your generated/memoed hash
.