finish function for output ranges

Johannes Pfau nospam at example.com
Sun Aug 12 01:36:00 PDT 2012


Am Sat, 11 Aug 2012 19:29:53 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> 2. The other is, the hash accumulator is an output range - a sink! - 
> that supports put() for a lot of stuff. Then the code would go:
> 
> HashAccumulator ha;
> copy([1, 2, 3], ha);

This is a little off topic, but when I implemented the recent changes
for std.hash I noticed the above code doesn't work, as ha is passed by
value. You currently have to do this:
ha = copy([1, 2, 3], ha); //or
copy([1, 2, 3], &ha);

> I think we should reify the notion of finish() as an optional method
> for output ranges. We define in std.range a free finish(r) function
> that does nothing if r does not define a finish() method, and invokes
> the method if r does define it.
> 
> Then people can call r.finish() for all output ranges no problem.

Sounds good.
> 
> For files, finish() should close the file (or at least flush it - 
> unclear on that). I also wonder whether there exists a better name
> than finish(), and how to handle cases in which e.g. you finish() an
> output range and then you put more stuff into it, or you finish() a
> range several times, etc.

The current behavior in std.hash is to reset the 'HashAccumulator' to
it's initial state after finish was called, so it can be reused. Finish
does some computation which leaves the 'HashAccumulator' in an invalid
state and resetting it is cheap, so I thought an implicit reset is
convenient.

I'm not sure about files.

The data property in Appender is also similar, but it doesn't modify
the internal state AFAIK, so it's possible to continue using Appender
after accessing data. It's probably more a peek function than a finish
function.

Probably we should distinguish between finish functions which destroy
the internal state and peek functions which do not modify the internal
state.
The implicit reset done in the hash finish functions would probably
have to be removed then. The downside of this is that it's then possible
to have a 'HashAccumulator' with invalid state, so 'put' would have to
check for that (at least in debug mode). With the implicit reset it's
not possible to get a 'HashAccumulator' with invalid state.


More information about the Digitalmars-d mailing list