Are iterators and ranges going to co-exist?

Peter Alexander peter.alexander.au at gmail.com
Wed Jul 21 10:00:56 PDT 2010


== Quote from Walter Bright (newshound2 at digitalmars.com)'s article
> If some algorithms used ranges and others used iterators, the
poor programmer
> would find himself then obliged to implement both interfaces for
each container.

This makes no sense.

I don't understand why you see ranges and iterators as conflicting
concepts. The cursors/iterators are for referring to individual
elements, and ranges are for specifying iterations over a sequence.

There aren't two competing interfaces here. If your interface
requires a range of elements, you use a range. If it only needs a
single element, you use a cursor.

For example, sort would always take a range, as it is sorting a
range, not a single element. I *do not* propose that we start
writing sort(Iter begin, Iter end) as that is much less flexible
than a range, and as you say, it is much harder to validate.

An example of an algorithm that would take a cursor is
insertBefore. There is no reason for it to accept a range, because
you are not traversing elements. You just want to insert something
before some single point in the range.


> > All I would like to see is some way to generically point to a
> > single element in a range.
> range[0] ?

That only works on arrays, therefore it is not generic.


> There is the massive unsafeness of using iterators. We'd like
the whole of the
> algorithms to be guaranteed memory safe, and that cannot happen
with iterators.
> Being able to statically guarantee memory safety is a huge deal,
and the larger
> a program is and the larger the team working on it, the more
this matters.

The iterators would not need to be used for iterations. Ranges do
a perfectly fine job of that already. They would only be used for
referring to individual elements.





More information about the Digitalmars-d mailing list