Am Wed, 08 Aug 2012 11:27:49 +0200 schrieb Piotr Szturmaj <bncr...@jadamspam.pl>:
> > BTW: How does it work in CTFE? Don't you have to do endianness > > conversions at some time? According to Don that's not really > > supported. > > std.bitmanip.swapEndian() works for me Great! I always tried the *endianToNative and nativeTo*Endian functions. So I didn't expect swapEndian to work. > > > Another problem with prevents CTFE for my proposal would be that the > > internal state is currently implemented as an array of uints, but > > the API uses ubyte[] as a return type. That sort of reinterpret > > cast is not supposed to work in CTFE though. I wonder how you > > avoided that issue? > > There is set of functions that abstract some operations to work with > CTFE and at runtime: > https://github.com/pszturmaj/phobos/blob/master/std/crypto/hash/base.d#L66. > Particularly memCopy(). I should definitely look at this later. Would be great if hashes worked in CTFE. > > And another problem is that void[][] (as used in the 'digest' > > function) doesn't work in CTFE (and it isn't supposed to work). But > > that's a problem specific to this API. > > Yes, that's why I use ubyte[]. But then you can't even hash a string in CTFE. I wanted to special case strings, but for various reasons it didn't work out in the end. > > I don't think std.typecons.scoped is cumbersome: > > auto sha = scoped!SHA1(); // allocates on the stack > auto digest = sha.digest("test"); Yes I'm not sure about this. But a class only based interface probably hasn't high chances of being accepted into phobos. And I think the struct interface+wrappers approach isn't bad. > > Why I think classes should be supported is the need of polymorphism. And ABI compatibility and switching the backend (OpenSSL, native D, windows crypto) at runtime. I know it's very useful, this is why we have the OOP api. It's very easy to wrap the OOP api onto the struct api. These are the implementations of MD5Digest, CRC32Digest and SHA1Digest: alias WrapperDigest!CRC32 CRC32Digest; alias WrapperDigest!MD5 MD5Digest; alias WrapperDigest!SHA1 SHA1Digest; with the support code in std.hash.hash 1LOC is enough to implement the OOP interface if a struct interface is available, so I don't think maintaining two APIs is a problem. A bigger problem is that the real implementation must be the struct interface, so you can't use polymorphism there. I hope alias this is enough.
