New hash API: Update

[Jonathan M Davis]

On Monday, June 25, 2012 11:30:41 Johannes Pfau wrote:
> Am Sun, 24 Jun 2012 21:40:53 +0200
> 
> schrieb Alex Rønne Petersen <alex at lycus.org>:
> > Also, most (if not all) Digest methods really should be pure nothrow.
> > Same for some free functions (I think it's good practice to mark
> > template functions as pure nothrow explicitly if you want to
> > guarantee this).
> 
> I still don't understand pure on member functions completely. The this
> pointer is considered as a function parameter, right?
> 
> So even put, start, reset... can be pure as those produce the same
> result as long as they receive the same arguments and the same _this_
> 'state'?
> 
> I tried to add pure to the interface, but I seems it's not a good idea
> right now. It doesn't work for the SHA1 implementation for example
> cause that uses memcpy.

_All_ that pure means by itself is that a function does not access any mutable 
global or static variables and that it does not call any functions which are 
not pure. It means _nothing_ more. There are _zero_ guarantees that the 
function will return the same result or anything like that. It's what we 
sometimes term a weakly pure function. That's all pure is by itself.

A strongly pure function, on the other hand, is a pure function whose 
arguments are all either immutable or implicitly convertible to immutable. And 
because that guarantees that the function's arguments won't be mutated, and 
because you have the guarantee that that function and any function it calls 
cannot access any state which isn't passed to it via those immutable arguments 
or which it creates itself, the compiler can guarantee that calling that 
function with the same arguments multiple times will result in the same return 
value.

So, in general, _all_ that you're really guaranteeing when you mark a function 
pure is that it's not accessing mutable global or static state either directly 
or via any functions that it calls. There are then cases where the compiler 
can generate improved guarantees based on that information (e.g. when the 
function is strongly pure), but that's arguably a detail of the compiler's 
optimizer.

David Nadlinger wrote up an article on it not to long ago which may help 
clarify matters (though I still haven't gotten around to reading it, so I 
don't really know how good it is), so you may want to check that out:

http://klickverbot.at/blog/2012/05/purity-in-d/

- Jonathan M Davis