ch-ch-changes

[Andrei Alexandrescu]

Denis Koroskin wrote:
> 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"?
> 
> 

Whoa! I stack overflowed just re-reading that! :o) Thanks.

Andrei