www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - hashOf()

reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
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?
Nov 02 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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.
Nov 02 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Nov 02 2016
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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(...)`
Nov 02 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Nov 03 2016
parent =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
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...
Nov 03 2016