Am Sat, 11 Aug 2012 19:29:53 -0400 schrieb Andrei Alexandrescu <seewebsiteforem...@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.
