Are iterators and ranges going to co-exist?

[Rainer Deyke]

On 7/20/2010 01:39, Peter Alexander wrote:
> Iterator is probably a bad name for describing this concept, as it
> implies that they have the same usage as ranges, but they do not. An
> iterator/cursor points to one element -- a generic pointer if you like.
> Ranges define a self-sufficient machine for iteration, which makes them
> overkill (and unwieldy) when you just want to refer to one element.

I agree with this.  Ranges are great for iterating, but iterators are
better for defining ranges.  This leads to confusion.

The great strength of STL-type iterators is that you can easily refer to
any single element or any range of elements out of a sequence.

Take, for example, the 'find' algorithm.  When I use 'find' in C++, I
use it to find a position, not an element.  I can do any of the following:
  - Iterate through all the items after the found item.
  - Iterate through all the items before the found item.
  - Iterate through all the items before the found item, and then
iterate through all the items after the found item, with just a single
search.
  - Find two items (in a random-access range) and compare the iterators
to see which one comes first.
  - Iterate through all the items /between/ two found items.

The last one is especially interesting to me.  STL-style iterators allow
me to easily define a range by specifying two end points, even if the
end points come from different sources.  I don't think this is possible
with D-style ranges.  It's certainly not possible in any clean way,
because D-style ranges have no provision for specifying individual
positions in a sequence.


-- 
Rainer Deyke - rainerd at eldwood.com