On Sunday, August 12, 2012 03:20:49 Walter Bright wrote: > On 8/12/2012 1:36 AM, Johannes Pfau wrote: > > Probably we should distinguish between finish functions which destroy > > the internal state and peek functions which do not modify the internal > > state. > > I worry about too many parts to an interface. > > A peek function needs a really strong use case to justify it.
The big question is whether it's merited in output ranges in general. A function could still be worth having on an individual type without making sense for output ranges in general as long as it's not required to use the type. However, I really don't think that peek makes sense for output ranges in general. Most of the time, you're just writing to them and not worrying about what's already been written. It's basically the same as when you write to a stream. I don't think that I've seen a peek function on an output stream. And I really don't think that peek makes sense in the context of hashes. You don't care what a hash is until it's finished. And once it's finished, it really doesn't make sense to keep adding to it. I don't know why you'd ever want an intermediate hash result. If you call finish, you're done. And if finish gets called again, it's just like if you call popFront after an input range is empty. The behavior is undefined (though popFront - or finish in this case - probably has an assertion for checking in non-release mode). I really don't think that it's all that big a deal. - Jonathan M Davis