RFC on range design for D2

[Steven Schveighoffer]

"Bill Baxter" wrote
> So far though we don't seem to be able to come up with a good example
> other of where ranges are weak than traversing a list back and forth.
> Note that "move back and forth according to some user input" is not
> clearly not an "algorithm" that would be in std.algorithm.  But it
> does come up often enough in applications.  I don't think the fact
> that it's not strictly an Algorithm-with-a-captial-A makes it any less
> important.
>
> But it is a little fishy that we can't come up with any other example
> besides sliding a bead on a wire back and forth.

Any structure that might change topology doesn't lend itself well to 
persistant ranges.  Ranges are fine for iterating over a constant version of 
the container.  i.e., if you want to implement a search function, where you 
are assuming that during the search, the container doesn't change, that 
should take a range as an argument.  But storing references to individual 
elements for later use (such as O(1) lookup or quick removal), and modifying 
the container inbetween getting the reference and using the reference makes 
it difficult to guarantee the behavior.  The only range type that seems like 
it would be immune to such changes would be the empty range where both ends 
point to the same element.  In fact, this can be reduced to a single 
reference, just copied for the sake of calling it a 'range'.

Arrays are really a special case where the ranges unequivocally work because 
once you get a range, all of it is guaranteed not to disappear or change 
topology.  i.e. a slice always contains valid data, no matter what you do to 
the original array.  I think this is the model Andrei is trying to achieve 
for all containers/iterables, and I think it's just not the same.  I think 
passing the range around as one entity is a very helpful thing, especially 
for algorithms which generally take ranges in the form of 2 iterators, but I 
don't think it solves all problems.

-Steve