== Quote from Walter Bright (newshou...@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.
