Stewart, Robert wrote:
Andrei is far better able to defend his notion of Ranges than I, given the time he's spent working on the idea. However, I don't yet accept as axiomatic that all ranges can be expressed as a pair of iterators.
The bottom line is if ranges can be made to very reasonably support all use cases, their other benefits (ease of specification, implementation, and composition) make supplanting iterators with ranges highly desirable.
Good points (also those I snipped too, I just have a high-level response). I'm pretty sure most of what ranges do, iterators can be made to do with enough effort and attention because iterators are lower level. The problem is, the effort in defining and manipulating such abstractions is just too high. (And programmers voted with their code: there just aren't that many awesome iterators out there.) For one, the designs feel off-key - for example, std::istream_iterator, with its useless "end" iterator, just hurts. Or if you want to express a random number generator or a mathematical series, how naturally are they modeled with iterators? And then how easy is it to manipulate all of the above? One secondary issue is that designs with iterators are so unduly complex, we got used to the idea that a container offers ONE iterator (and one const_iterator). This is just odd if you look at it with a fresh eye. How about multidimensional containers? Should there really be only one way to span them? Ranges eliminate enough of the unneeded complexity to allow you to define several ranges that work on a container type. Conversely, there are designs that are more efficient with iterators. I think those are few and far apart enough to not render me worried. Andrei