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
