hashOf()

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Nov 3 06:11:41 PDT 2016


On 11/2/16 12:14 PM, Márcio Martins wrote:
> There are 2 hashOf() definitions, one in object.d and one in
> core.internal.hash.d
>
> If you include core.internal.hash, you cannot call hashOf() anymore,
> because it conflicts with the implicit import in object.d, this is
> annoying in itself...
> The bigger issue though, is that they have different semantics:
>
> import core.internal.hash : hashOfInt = hashOf;
>
> void main() {
>     string moo = "moo";
>     assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes
> moo.ptr[0..moo.length]
>     assert(moo.hashOf == moo.idup.hashOf); // fail - hashes
> &moo[0..moo.sizeof]
> }
>
> Did anyone else fall into this trap?

You are not the only one:

https://forum.dlang.org/post/nv85ou$gi5$1@digitalmars.com

Note, I wholly disagree with the idea that hashOf(arr) hashes the 
pointer and length elements. I get why it does, and get what the charter 
of hashOf is. But nobody expects it.

IMO, hashOf should fail to compile on types that contain pointers, 
including arrays. In fact, I'm thinking hashOf shouldn't even be 
available in object. It's completely inconsistent with all other forms 
of hashing a type (which use typeinfo, opHash, etc.). It's too 
low-level, and should be accessible only via an import.

-Steve


More information about the Digitalmars-d mailing list