Forward Range(s)

[Jonathan M Davis]

On Sunday, August 26, 2012 23:20:49 Era Scarecrow wrote:
> On Sunday, 26 August 2012 at 18:07:27 UTC, Jonathan M Davis wrote:
> > But it would be better IMHO to just fix it so that your range
> > is a forward range, since there's no reason for it not to be.
> 
> That brings up my own question. I'm writing an application that
> will end up using an output range (likely an appender, so
> semi-dynamic). How will I be sure that what's passed to other
> functions will append to the range? And more importantly, if I
> use save and then rewrite an earlier section (due to updated
> information) would that also be correct assuming memory didn't
> change on it? Can you give an example?
> 
> Currently my code goes something like this:
> 
> struct ... {
> innerType[] someInnerType;
> 
> void write(T)(T outputRange)
> if(isForwardRange!(T)){
> 
> auto firstBlock = outputRange.save;
> //write to outputRange, first output will be re-written
> writeFirstBlock(outputRange);
> 
> foreach(ref i; someInnerType) {
> i.write(outputRange);
> }
> 
> //updated information for first block
> writeFirstBlock(save);
> }
> }

I don't think that I really understand the question, but I'd be worried about 
intermixing save with operating on a range as an output range. It _should_ 
work, but save was designed with reading in mind, not writing. An output range 
doesn't have to have save or even front or popFront. All it needs is to work 
with put. Output ranges are a very different beast from input ranges, even if 
input ranges can be output ranges.

That being said, I'd expect that save would save the current state, and any 
writing to the original would not affect the saved range.

- Jonathan M Davis