The review of std.hash package

[Johannes Pfau]

Am Wed, 08 Aug 2012 16:44:03 -0400
schrieb "Jonathan M Davis" <jmdavisProg at gmx.com>:

> > 
> > in CTFE?
> > http://dpaste.dzfl.pl/0503b8af
> > 
> > According to Don reinterpret casts (even if done through unions)
> > won't be supported in CTFE. So you can't convert from
> > uint-->ubyte[4]
> 
> No. It wouldn't work in CTFE, because it uses a union.But what it's
> trying to doesn't really make sense in CTFE in most cases anyway,
> because the endianness of the target machine may not be the same
> endianness as the machine doing the compilation. Any computations
> which cared about endianness must be in a state where they don't care
> about endianness anymore once CTFE has completed, or you're going to
> have bugs.

I completely agree, but this is true for hashes. Once the final hash
value is produced it doesn't depend on the endianness.

> 
> Though if the issue is std.hash being CTFEable, I don't know why
> anyone would even care. It's cool if it's CTFEable, but the sorts of
> things that you hash pretty much always require user or file input of
> some kind (which you can't do with CTFE).

Yeah it's not that useful, that's why I didn't care about CTFE support
right now. The only usecase I can think of is to hash a string in CTFE,
for example UUID could use it to support name based UUID literals.

> You'd have to have a use
> case where something within the program itself needed to be hashed
> for some reason for it to matter whether std.hash was CTFEable or
> not, and it wouldn't surprise me at all if it were typical in hash
> functions to do stuff that isn't CTFEable anyway.
> 
> - Jonathan M Davis