A coworker asked about the idiomatic way to get the hash of a string in D, and somewhat surprisingly the best answer I could find is: "to get the hash of an lvalue x, call typeof(x).getHash(&x)."

That's admittedly quite clunky and indirect. Is it worth it to simplify that by means of a template in object.di?


Andrei

Am 31.07.2014 03:07, schrieb Andrei Alexandrescu:
> A coworker asked about the idiomatic way to get the hash of a string in
> D, and somewhat surprisingly the best answer I could find is: "to get
> the hash of an lvalue x, call typeof(x).getHash(&x)."
>
> That's admittedly quite clunky and indirect. Is it worth it to simplify
> that by means of a template in object.di?
>
>
> Andrei

I proposed something like the following in another thread and think it would be really useful (to implement toHash() amongst other things):

hash_t createHash(T...)(T args)
{
   // return a hash over all arguments
}

In that thread (I think it was "WAT: opCmp and opEquals woes") it was implied that currently the compiler generates a toHash() automagically by hashing all members (of a struct or class) - analogous to opEquals that just compares all members.
I can't find any documentation on that behavior.. but if it indeed exists there must already be a sensible hash algorithm for multiple values of different types which could just be reused here.

Of course hashing a single value is just a special case of this.

Cheers,
Daniel

On Wed, Jul 30, 2014 at 06:07:57PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> A coworker asked about the idiomatic way to get the hash of a string
> in D, and somewhat surprisingly the best answer I could find is: "to
> get the hash of an lvalue x, call typeof(x).getHash(&x)."
> 
> That's admittedly quite clunky and indirect. Is it worth it to simplify that by means of a template in object.di?
[...]

It's about time somebody noticed this!!

Why don't we just expose druntime's core.internal.hash.hashOf() function somewhere? It's not as though it isn't already in druntime, so the function is already present in the executable, we just need a public declaration of it somewhere that users can make use of.

Not to mention, it's already a template function that correctly calculates the hash of various built-in types.


T

-- 
The problem with the world is that everybody else is stupid.

On Thursday, 31 July 2014 at 17:39:43 UTC, H. S. Teoh via Digitalmars-d wrote:
> It's about time somebody noticed this!!
>
> Why don't we just expose druntime's core.internal.hash.hashOf() function
> somewhere? It's not as though it isn't already in druntime, so the
> function is already present in the executable, we just need a public
> declaration of it somewhere that users can make use of.
>
> Not to mention, it's already a template function that correctly
> calculates the hash of various built-in types.
>
>
> T

I've often just put "import core.internal.hash;" in my code.

Once we get this solved we need to work on the fact that many hash generation functions are not pure. (Object.toHash not being pure prevents a lot of containers from being used in pure templated code)

On Thu, Jul 31, 2014 at 07:08:16PM +0000, Brian Schott via Digitalmars-d wrote:
> On Thursday, 31 July 2014 at 17:39:43 UTC, H. S. Teoh via Digitalmars-d wrote:
> >It's about time somebody noticed this!!
> >
> >Why don't we just expose druntime's core.internal.hash.hashOf() function somewhere? It's not as though it isn't already in druntime, so the function is already present in the executable, we just need a public declaration of it somewhere that users can make use of.
> >
> >Not to mention, it's already a template function that correctly calculates the hash of various built-in types.
> >
> >
> >T
> 
> I've often just put "import core.internal.hash;" in my code.
> 
> Once we get this solved we need to work on the fact that many hash generation functions are not pure.

I'm not sure I understand why. Un-@safe (probably should be @trusted) I can understand, since you basically have to treat arbitrary typed data as ubyte[] in order to compute the hash, but impure? I don't see it. The definition of hash function requires that its output depend only on its input(s), so why can't it be pure?


> (Object.toHash not being pure prevents a lot of containers from being
> used in pure templated code)

Yeah, this is one of the things that prompted us to move towards removing toHash from Object.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.

On 07/31/2014 09:40 PM, H. S. Teoh via Digitalmars-d wrote:
> The definition of hash function requires that its output depend only on its
> input(s), so why can't it be pure?

For example, because it might actually be random on the first invocation and cached later. :-)

http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/java/lang/Object.java#l101

http://blogs.tedneward.com/CommentView,guid,eca26c5e-307c-4b7c-931b-2eaf5b176e98.aspx (caution, broken script, didn't find a better source to quote quickly.)

On Thursday, 31 July 2014 at 22:45:44 UTC, Timon Gehr wrote:
>
> For example, because it might actually be random on the first invocation and cached later. :-)

This is interesting.
Some hash functions in druntime might break in an environment with a precise moving GC.