ch-ch-changes

[Jason House]

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

I think algorithm signatures should not be made unnecessarily complex, and instead rely on other utilities for complex behavior.  For example
map!("a*a")(r1,r2) can be implemented as map!("a*a")(chain(r1,r2))

I also see in the docs that the structs returned are documented, complete with all the functions that they include.  I'd hope that we could somehow document this stuff simpler... 

Maybe the following?
outputRangeType!(r) map!(fun)(r)

note also how accepting only one range also makes documenting the return type easier ;)