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