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?

On Wednesday, 2 November 2016 at 16:14:23 UTC, 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?

I think that "internal" means "for internal use", I.e. don't import and use it outside.

You could argue that object.hashOf should hash the contents of slices, not just the meta-data (i.e. length / ptr), but that's a separate matter.

On Wednesday, November 02, 2016 16:19:44 John Colvin via Digitalmars-d wrote:
> I think that "internal" means "for internal use", I.e. don't import and use it outside.
>
> You could argue that object.hashOf should hash the contents of slices, not just the meta-data (i.e. length / ptr), but that's a separate matter.

Yeah. Don't use anything in an internal package in either druntime or Phobos. And now that we can do stuff like package(std), it should be possible to fix it so that those symbols _can't_ be imported while still being usable by other code inside the higher level package. Previously, the only way to have core.internal accessible by the rest of core was to have it be public, which then didn't actually prevent you form doing stuff like importing it in your own code even though you shouldn't. So, core.internal should be fixed to use package(core).

- Jonathan M Davis

On Wednesday, 2 November 2016 at 16:14:23 UTC, Márcio Martins wrote:
> 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...

You should still be able to call it with the full name, `object.hashOf(...)` vs `core.internal.hash.hashOf(...)`

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

On Thursday, 3 November 2016 at 13:11:41 UTC, Steven Schveighoffer wrote:
> On 11/2/16 12:14 PM, Márcio Martins wrote:
>> [...]
>
> 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

That's what I'd expect as well. The hashOf() in core.internal.hash is useful, and it works intuitively, IMO, so if one is implicitly imported it should be that one...