finish function for output ranges

[Jonathan M Davis]

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