Are iterators and ranges going to co-exist?

[Jonathan M Davis]

On Monday, July 19, 2010 14:24:24 Peter Alexander wrote:
> On 19/07/10 9:47 PM, Andrei Alexandrescu wrote:
> > The plan is to use ranges everywhere. Sorry to disappoint. If you can
> > find solid arguments for introducing iterators, of course it would be
> > great if you discussed them in this group.
> 
> Well, you mentioned a few yourself in your article.
> 
> - With ranges, you double the size of "iterators", which increases the
> memory usage of something like Boost.MultiIndex.
> 
> - It makes certain algorithm interfaces awkward, such as rotate. I know
> you proposed to pass in two ranges, but to me that seems like an
> desperate attempt to force ranges into an interface that wants
> iterators. In the case of rotate, you've now burdened the programmer
> with assuring that the ranges are adjacent (which will probably involve
> introducing a local variable for maintenance/readability reasons), and
> you've also increased the amount of data you need to pass into the
> function by 33%, violating the "Don't pay for what you don't use"
> philosophy.
> 
> - You're returning more data than is often wanted from some functions
> (such as the planned find).
> 
> - It makes something like STL's std::list::splice *very* awkward. To do
> splice in constant time (as you should) the "range" is going to need to
> know about the previous element to its front so that it can update the
> linked list. What is the planned interface for this?
> 
> 
> My biggest objection to this is that it is essentially an awkward
> attempt at abstracting iterators. Ranges are brilliant, and maybe you
> could even call them a superset of iterators, but just like we have
> vectors despite having matrices, and points despite having lines, we
> still want iterators even though we have ranges. They are simply
> different things.

The only time that I'm aware of where it makes any sense to have an iterator 
rather than a range is when you need to refer to a single element. And in almost 
all cases, a range with one element fits the bill just fine. For instance, I don't 
think that there is any problem whatsoever with find() being entirely range 
based. It gains nothing by doing anything with iterators.

Ranges do become awkward in some places - like if you want to remove what you're 
searching with find() from the container that you're searching in; you're forced 
to use take() on the range to feed it to the remove function rather than just 
giving it the result like you would in C++. However, you do gain a lot in 
genericity, and trying to force iterators into it would harm that.

It may be that something else needs to be done in addition to ranges as they 
stand (like maybe putting a wrapper around a range which effectively turns it 
into an iterator on its first element for those few algorithms which would do 
better with an iterator), but I really haven't found there to be a problem with 
the lack of iterators. It does require some changes in thinking, but I'd 
hesitate before trying to mix iterators into the mix.

- Jonathan M Davis