forward ranges must offer a save() function

[Andrei Alexandrescu]

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