Miserable instances for integral types about hashable HOT 2 CLOSED

The combining function was good when we had a good hash function for integers. Unfortunately, the hash function got reverted back to the identity function, but the combining function remained the same as it had been :-(

from hashable.

The list instance is fixed by 4064b9f. The definition folds hashWithSalt with an initial non-zero seed so the numbers of elements in the list matters:

ghci> hash ([] :: [Int])
-2578643520546668380
ghci> hash ([0] :: [Int])
839657738087498284
ghci> hash ([0, 0] :: [Int])
-7234408896634655932

We don't really care that tuples of different size (e.g. (0, 0) and (0, 0, 0)) hash to the same value, as the only way you end up using both instances simultaneously is if you use an existential wrapper type, in which case you're already in deep waters.

Aside: 0 is only a left identity of the current combine implementation (which uses multiplication and xor), not a right identity.

from hashable.