RFC on range design for D2

[Jason House]

Steven Schveighoffer Wrote:

> "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.  

Who says all ranges have to be persistant? Ranges "from here to the end" can be dynamic similar to an iterator. 

In my mind, the important cdiscussion is what "end" means and to compare when ranges and iterators get invalidated. 
I also wonder a bit about mixing ranges with non-iterable cursors. Of course, their limited value may not merit the complexity.






  

> 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 
> 
>