• Steven Schveighoffer (30/30) Oct 08 2023 I was looking at the documentation for `hashOf`, and discovered this
• Steven Schveighoffer (9/20) Oct 08 2023 I've settled on the following "solution":

Steven Schveighoffer <schveiguy gmail.com> writes:

I was looking at the documentation for `hashOf`, and discovered this 
disturbing [documentation 
note](https://dlang.org/phobos/object.html#.hashOf):

```
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](https://dlang.org/changelog/pending.html#dmd.static-assoc-array), 
as it uses `hashOf` under the assumption it will be identical to the 
`getHash` method (which cannot be used at compile time).

-Steve

Steven Schveighoffer <schveiguy gmail.com> writes:

On 10/8/23 11:24 AM, Steven Schveighoffer wrote:
 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.

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