forward ranges must offer a save() function

[Steven Schveighoffer]

On Sat, 30 May 2009 13:18:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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; }

I have two questions that came to mind:

1. What is the use case for classes as ranges?  I can't think of one.   
With structs, you can control the aliasing behavior when it is copied, so  
the issue is less critical.

2. Even if there is a use case, why put the band-aid on the ranges that  
aren't affected?  That is, why affect all ranges except input ranges when  
input ranges are the issue?  Even if this does work, you are going to have  
mistakes where you copy the range instead of calling .save, which will  
compile successfully.  Since you have to special case it, why not just put  
a flag in the non-copyable input ranges?  Like an enum noCopy = true; or  
something.  Then you can special case those and have them fail to compile  
when they don't support the algo.  For classes, you wouldn't need to do  
this, because they are by default reference types, and this can be  
statically checked.

The point is, make the frequent usage easy, and the one-time range design  
require the careful usage.

-Steve