Can someone please explain why the following assertion fails?

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 10:08 AM, Steven Schveighoffer wrote:
> On 10/31/16 3:24 PM, Ali Çehreli wrote:
>> Because it considers the .ptr property of arrays as well:
>>
>>
[snip]
>>         return bytesHash(bytes.ptr, bytes.length, seed);    // <-- HERE
>
> bytesHash shouldn't use the pointer value in any way, it should just use
> the pointer to look at the bytes.

And the issue is not there it is simpler than that. Here is the entire 
definition of hashOf 
(https://github.com/dlang/druntime/blob/master/src/object.d#L3176):

size_t hashOf(T)(auto ref T arg, size_t seed = 0)
{
     import core.internal.hash;
     return core.internal.hash.hashOf((cast(void*)&arg)[0 .. T.sizeof], 
seed);
}

Note that if arg is a string, then it's going to take the hash of the 
bytes that define the dynamic array pointer and length. Not at all what 
the user is expecting. Would be even more surprising for an object 
reference or pointer.

I'm not sure what the bug is here. It's quite possible the intention is 
to provide a low-level primitive that avoids all hashing customization.

However, to have it called hashOf, and then have another internal 
function called hashOf that does something different, is quite 
surprising and error prone. Indeed, I think Ali did not realize where 
the definition of hashOf was coming from.

At the very least, the documentation needs updating.

-Steve