ch-ch-changes

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> 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
> 
> Wow.  That looks truly amazing!  I can't wait until it's released so I can try it
> out!  At first glance, my only constructive criticism is that, in Proxy, I'd
> ideally like to see standard D tuples used, meaning:
> 
> auto foo = a[0];  // instead of:
> auto bar = a.at!(0);
> 
> This might require a few changes to the core language to support.  However, it
> would give the power of the builtin tuples to Proxy structs, such as iterating
> over the members with foreach and passing a tuple to a function.

Yes, I find it jarring as well. I will submit an enhancement request.

Andrei