I was looking at the documentation for hashOf, and discovered this disturbing documentation note:

The result might not be equal to typeid(T).getHash(&arg).

Why? I looked into the history of hashOf. it was added back in 2014: https://github.com/dlang/druntime/pull/989

With the note from that first commit.

At the bottom, you will see a note 2 years later, indicating that the hashOf function just calculates the hash based on the bits of the type, not based on any toHash function in the type itself, etc.

That was done at a later time (the original did seem to try and match both typeid(T).getHash and hashOf despite the note).

And that problem was reverted, fine.

But the problem I see here is that hashOf is provided by druntime, and TypeInfo.getHash is provided by druntime. Both of these should be exactly the same.

I want to know:

a) why was the note added?
b) can we get rid of the note (with appropriate unittests)?
c) I found one example where they don't match, double[2]. Can anyone find other types that fail? I think we should fix these so they are the same.

NOTE: this is very important for the upcoming fix to allow static associative arrays to be initialized at compile time, as it uses hashOf under the assumption it will be identical to the getHash method (which cannot be used at compile time).

-Steve

On 10/8/23 11:24 AM, Steven Schveighoffer wrote:

I've settled on the following "solution":

1. I will add a new hashOfAA function that performs the same as TypeInfo.getHash
2. Most of these calls will just forward to hashOf
3. The ones that might differ, I will follow whatever TypeInfo does.
4. Add all the unittests to make sure all the types hash the same at compile time, runtime, and via typeinfo.

-Steve