Am Wed, 08 Aug 2012 16:44:03 -0400 schrieb "Jonathan M Davis" <jmdavisp...@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