On 08/26/2012 02:46 PM, David wrote:
> Sorry, dmd 2.060

Hmmm. I use 2.060 as well.

Ali

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

On Monday, 27 August 2012 at 20:46:18 UTC, Jonathan M Davis wrote:
> 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.

 Well the first block actually holds size information and the information it holds is the old information, stuff may have been added or taken away, so hopefully not to have to do two passes (a dummy pass and then a real one) I was hoping save would save the location. If it doesn't reference the previous location using the current data then I'll need to figure something out.

 It's this that's been holding off one of my projects for a while as I'm not sure how to best approach it.