Am Thu, 31 May 2018 18:12:35 -0700 schrieb Manu: > Hashing's not low-level. It would be great if these did CTFE; generating > compile-time hashes is a thing that would be really useful! > Right here, I have a string class that carries a hash around with it for > comparison reasons. Such string literals would prefer to have CT hashes. >
As I was the one who wrote that doc comment: For basically all hash implementations you'll be casting from an integer type to the raw bytes representation somewhere. As the binary presentation needs to be portable, you need to be aware of the endianess of the system you're running your code on. AFAIR CTFE does (did?) not provide any way to do endianess-dependent conversions at all and there's also no way to know the CTFE endianess, so this is a fundamental limitation. (E.g. if you have a cross-compiler targeting a system with a different endianess, version(BigEndian) will give you the target endianess. But what will actually be used in CTFE?). I don't know if anything changed in this regard since std.digest was written some time ago. But if you get the std.bitmanip nativeTo*Endian and *EndianToNative functions to work in CTFE, std.digest should work as well. There may be some workaround, as IIRC druntimes core.internal.hash works in CTFE? It's either this, or it's buggy in that cross-compilation scenario ;-) -- Johannes
