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