ch-ch-changes

[Don]

Andrei Alexandrescu wrote:
> I've worked valiantly on defining the range infrastructure and making 
> std.algorithm work with it. I have to say that I'm even more pleased 
> with the result than I'd ever expected when I started. Ranges and 
> concepts really make for beautiful code, and I am sure pretty darn 
> efficient too.
> 
> There's a lot to sink one's teeth in, but unfortunately the code hinges 
> on a compiler fix that Walter was kind enough to send me privately. I 
> did document the work, but the documentation doesn't really make justice 
> to the extraordinary possibilities that lay ahead of us. Anyhow, here's 
> a sneak preview into the up-and-coming ranges and their algorithms.
> 
> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_range.html
> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_algorithm.html
> 
> Ranges are easy to define and compose efficiently. It was, however, a 
> pig to get a zip(r1, r2, ...) working that can mutate back the ranges it 
> iterates on. With that, it's very easy to e.g. sort multiple arrays in 
> parallel. Similarly, chain(r1, r2, ...) is able to offer e.g. random 
> iteration if all components offer it, which means that you can do crazy 
> things like sorting data that sits partially in one array and partially 
> in another.
> 
> Singly-linked list ranges are in, and to my soothing I found an answer 
> to the container/range dichotomy in the form of a topology policy. A 
> range may or may not be able to modify the topology of the data it's 
> iterating over; if it can, it's a free-standing range, much like 
> built-in arrays are. If it can't, it's a limited range tied to a 
> container (of which I defined none so far, but give me time) and it's 
> only the container that can mess with the topology in controlled ways. 
> More on that later.
> 
> Feedback welcome.
> 
> 
> Andrei

Awesome stuff. Will take some time to adjust my thought processes for this.
Some minor comments:
* Is Repeat simply a single-parameter form of Cycle? I can't see any 
difference between them.
* Uniq docs should at least add one word:  Iterates [[consecutively]] 
unique elements of the given range.
* find:
To find the last element of [[a bidirectional]] haystack satisfying 
pred, call find!(pred)(retro(haystack)).

(unless Retro also works for forward ranges, which seems unlikely).

* There's no pushHeap. Is it planned?