Re: hash_value( complex<T> )

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2021-10-17 00:28:10

On Oct 16, 2021, at 7:58 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> 
> Howard Hinnant wrote:
>> Given two values x and y, if x == y, it is convenient for hash(x) == hash(y).
>> 
>> In this situation, given a floating point value r, complex{r) == r, so it makes
>> sense that hash(complex{r}) == hash(r).  This might enable heterogeneous
>> hash table lookup.
> 
> But that already doesn't hold in general for int/long, float/double,
> int/double, and so on.

True, but it also doesn’t not hold. :-)

So it’s a design question:  should equal values hash equal, even if they are different types?

The rationale for yes is to enable heterogenous lookup.

The rationale for no is that it is not done that way for nearly all types (excepting maybe complex/real, and I’m not sure about string/string_view).  There may also be performance penalties for supporting heterogeneous lookup this way because such exceptions might disable a “contiguously hashable” attribute (which isn’t really relevant for hash_combine).

So either way isn’t a slam dunk.  But I’ve offered a potential advantage on "the original behavior.”

Howard