forward ranges must offer a save() function

[Jason House]

Andrei Alexandrescu wrote:

> If we want to allow people to create ranges that are classes (as opposed
> to structs) the requirement for a save() function is a must. This is
> because copying class ranges with
> 
> Range copy = original;
> 
> only creates a new alias for original; the two share the same state.
> 
> So this solves our forward vs. input ranges dilemma quite nicely: the
> save() function at the same time allows distinction between the two
> (input ranges don't define a save() function) and also allows ranges to
> be implemented as classes as well as structs.
> 
> To summarize:
> 
> Input ranges: empty front popFront
> 
> Forward ranges: + save
> 
> Bidir ranges: + back popBack
> 
> Random-access ranges: + opIndex opIndexAssign
> 
> The disadvantage is that all non-input ranges must define save(), which
> is a trivial functions in most cases:
> 
> Range save() { return this; }
> 
> 
> 
> Andrei

What about passing of ranges into functions?  Does this mean that all 
algorithms must call save at the start of the algorithm?  Or will callers of 
functions have to do defensive saves to avoid changes to their range?  Maybe 
all ranges be passed as ref arguments now?  

I don't think the answer is as simple as just having a save function.