ch-ch-changes

[Denis Koroskin]

On Wed, 28 Jan 2009 12:52:03 +0300, Denis Koroskin <2korden at gmail.com> wrote:

> On Wed, 28 Jan 2009 07:15:25 +0300, 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.
>>
>>
>> Andrei
>
> Sweet!
>
> One note - "move" has a precondition: "!pointsTo(source, source)".  
> Shouldn't it be "!pointsTo(source, target)"?
>

The following sentence doesn't sound well to me:

template isForwardRange(R)
"The semantics of a forward range (...) are the same as for a forward range, ..."

Recursive definition? Should it say "are the same as for an input range"?