Stewart, Robert wrote:
That would limit ranges because there are ranges that are not pairs of iterators. All ranges can be expressed as pairs of iterators, so I hardly see how that limits anything.
Not true. Some ranges can be generated on the fly based upon a predicate (either provided or built into the range type). Ranges in the Boost.Range library are what you've described, but those in Andrei's scheme are not.
I don't see how your message disproves what I said (nor actually, how it is related at all). Boost.Range is just a set of tools to make it more practical to manipulate iterators pairs, which can represent ranges. Alexandrescu offers to ditch iterators and directly define first-class ranges. Yet, in terms of expressiveness, a pair of iterators is not less expressive than Alexandrescu's ranges (discuss below). The only gains there might be are ease-of-defining (but then, if you accept my argument iterators are needed anyway, that gain is moot) and efficiency (which becomes moot too if you allow the two iterators of the pair to be of different types).
The issue is that expressing a range as a pair of iterators may not always be optimal.
Expressing a range as a pair of iterators is not always possible.
They actually seem to be mostly equivalent, except Alexandrescu ranges lack the ability to compare positions. Do you have a single example of a range that can be expressed with Alexandrescu's concepts but not with iterators pairs? Not that unlike what the "Iterators must go" slides claim, iterators can implement the Stride operation just fine.