Re: hashOf()
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...
Re: 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
[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
Re: hashOf()
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(...)`
Re: hashOf()
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
Re: hashOf()
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
[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.
