ch-ch-changes

[Jarrett Billingsley]

On Tue, Jan 27, 2009 at 11:15 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> 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.

This is some awesome stuff.  std.range and std.algorithm are really
coming together into a compelling whole.  I don't know what else to
say - _you_ seem to know what you're doing!

It's a minor point, but in the docs, with all the templating madness
it gets very hard to find the name of the symbol actually being
documented.  For example:

Filter!(unaryFun!(pred),Chain!(Ranges)) filter(alias pred,
Ranges...)(Ranges rs);

"filter" gets lost in the middle.  Could it be highlighted, or moved
to the front (using a Pascal-like "func(params) : returntype" syntax
instead)?

Also - "toe" is still a stupid name.  ;)  "first" and "last" would
have been my first choices, they seem so obvious.