Are iterators and ranges going to co-exist?

[Peter Alexander]

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.