finish function for output ranges

[Dmitry Olshansky]

On 12-Aug-12 14:35, Jonathan M Davis wrote:
> 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.
>

Agreed. Current appender has .data (a-la peek) just because of 
implementation details that allow it. In fact there was a pull for 
Phobos including s better Appender (that would end up being a Builder I 
guess) that doesn't allow to peek at array in creation until the very 
end but provides much better performance profile.

BTW what's happened with that pull? I recall github nickname sandford, 
but can't recall whose awesome work that was. I'd love to see it make 
its way into Phobos.

> 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.
>

Having partial hashes over data is very useful e.g. for fast binary diff 
algorithms. However it requires specific form of hash function (so that 
you can look at result) and/or operating at specific block granularity.

> 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.

Agreed. finish seems as a good name because indicates that it's an end 
of operation. But consider that hash accumulator can be reset after 
finish and reused (unlike say network stream).

-- 
Dmitry Olshansky