Are iterators and ranges going to co-exist?

[Peter Alexander]

== Quote from Walter Bright (newshound2 at digitalmars.com)'s article
> The strongest reason against iterators is that they are
fundamentally unsafe, as
> Andrei explains in his paper about ranges. An iterator (as we
all know) is based
> on a pointer, and is often a thin veneer over a pointer. It
cannot be checked
> mechanically to determine if it is safe to increment or
dereference.
> The problem with supporting a dual range/iterator design in
Phobos is the
> library will lose focus, and will become a confusing morass.

I don't see how it is a dual design. Almost all the algorithms
that use ranges now would remain the same. I don't propose that
any of that should be changed.

All I would like to see is some way to generically point to a
single element in a range. I don't actually care about whether
these iterators/cursors can be incremented or not because ranges
are more useful for iteration. We just need some way to point to
single elements (and as I have said before, pointers are no good
in non-arraylike containers).

The only algorithms I would change are the ones that want
iterators/cursors to individual elements (like insertBefore etc.).
I would also add a rotate(Range r, Cursor middle) to *complement*
bringToFront.

I would personally also create a "Cursor find(Range r)", but I can
accept arguments for the more flexible version in the library.

This is not a massive change, and ranges would still comprise a
good 95% of the algorithm code; I just think it's odd to use
ranges for those 5% that would make more sense to use cursors.