I am made very uncomfortable, however when we put structs (and therefore, by a primary identity in the C++ language, classes) into the mix. Here we may have inheritance relationship (not a union) where two different types with different meanings to the quantities can end up introducing a tendency for rather different things to hash to the same values.
How so, there is no automatic hashing of classes or structs (since there is no reflection in C++), and different classes can't be stored in the same hash container anyway. It's true that a vector<int> and a deque<int> with the same contents would hash to the same value, but again vectors and deques can't be stored in the same indexed container, and I rather like the predictability that this offers: if I change my code from vector<int> to deque<int> I would expect hashes to behave in the same way (I don't care whether they produce the same values, but I do care that the risk of collisions is the same in either case, given that they are holding the same data). We could use a different seed value for each T ( hash_value(&typeinfo(T)) ? ), but that seems like overkill.
I presented the example of two different classes representing polar and Cartesian representation of complex numbers (and, yes, I have written packages where these two representations co-exist and intermix to allow optimizations).
Can you store these in the same container? If so then how could any implementation tell them apart anyway?
Of course for this example, you would clearly want a custom hash, but the point is, subclassing does not make this situation that bizarre. What about a table containing structs for Resources, which could represent either employees or pieces of office equipment where the characteristics of interest in each happen to all be represented as a bunch of booleans, that happen to be the same length?
Again, either the tables are the same type, and no implementation can tell them apart anyway, or they are different types, and they can't be mixed in the same container anyway. Would this concern be fixed by adding some information to the documentation? John.