The review of std.hash package

[Johannes Pfau]

Am Wed, 08 Aug 2012 11:27:49 +0200
schrieb Piotr Szturmaj <bncrbme at 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.