Difference between input range and forward range

[H. S. Teoh via Digitalmars-d]

On Tue, Nov 10, 2015 at 06:38:22PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Tuesday, 10 November 2015 at 17:16:41 UTC, Steven Schveighoffer wrote:
> >I've never made it a secret that I dislike the 'save' requirement. In
> >my experience, the only time you ever implement 'save' is to do the
> >same thing as copying the range via =. To the point where people
> >simply don't use the .save member, and their code always works, so
> >what is the point?  It may as well have been an enum isCopyable.
> 
> Well, it's not that hard to come up with a range that has to implement
> save, because copying it doesn't save it. The obvious example is if
> it's implemented as a class. Another would be std.range.refRange which
> exists specifically to turn a non-reference type range into a
> reference type range.  And really, any range that's an input range but
> not a forward range is in that boat, because if copying it duplicated
> it, then it could be a forward range.
> 
> I really don't see any way around having something like save without
> artificially restricting ranges to types which are implicitly saved
> when copied (which would pretty much mean getting rid of pure input
> ranges), but even if there were clearly a better way, that's a pretty
> big change at this stage.
[...]

There are a few ranges in Phobos that needs to do non-trivial things in
.save, that otherwise would not work properly. IIRC groupBy is one of
them. I'm pretty sure there are one or two others. I've also needed to
do this in my own code.

All it takes is for one range to need non-trivial implementation in
.save, and all the other wrapper ranges will need to do the same, in
order to be semantically correct (e.g., if they wrap around a range in
.r, then the copy returned by .save must have r = this.r.save, otherwise
the returned range will have side-effects on the original range).


T

-- 
Meat: euphemism for dead animal. -- Flora