On Sat, 30 May 2009 13:18:06 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
