Revised RFC on range design for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Sep 12 11:51:37 PDT 2008


Sergey Gromov wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
>> Sergey Gromov wrote:
>>> Bill Baxter <wbaxter at gmail.com> wrote:
>>>> On Fri, Sep 12, 2008 at 11:58 PM, Sergey Gromov <snake.scaly at gmail.com> wrote:
>>>>>> So basically you changed
>>>>>> done ==> empty
>>>>>> head ==> tip
>>>>>> retreat ==> prev
>>>>>> ?
>>>>> The insight was about get/put ==> next.  That's the most significant
>>>>> change, others are merely renames as you rightfully point out.  Hence
>>>>> the "prev" which should mean both "get at the end" and "put to the end".
>>>> Ah ok.  Your switching to declaration syntax instead of usage syntax
>>>> confused me. :-)
>>>>
>>>> That is cute.  So
>>>>    r.put(e) ==> r.next = e
>>>> It would also mean the copy to output idiom would become
>>>>
>>>> for(; ! i.done; i.next)
>>>>    o.next = i.head;
>>>>
>>>> Would be cooler if it could be just while(!i.done) o.next = i.next;
>>>> .. oh well.
>>> Exactly, I wanted it to be
>>>
>>> while (!i.done)
>>>     o.next = i.next;
>> Hmm, let's see. So:
>>
>> a) If i is an input range, then i.next returns by value.
>>
>> b) If i is a forward range, then i.next returns by reference.
>>
>> I assume that's what you had in mind?
> 
> Not quite.
> 
> You cannot mutate an input range, it must be in specs.  Therefore it's
> up to the range designer what to return.  LineEater will return a const 
> reference to an internal buffer.  RNG will return int.  Array will 
> return a const reference to its element.  Some could return a new class 
> instance every time.

Given that in D const is transitive, we can't operate with const the 
same way C++ does. Consider something as trivial as a copy:

Tgt copy(Src, Tgt)(Src src, Tgt tgt)
{
     for (; !src.done; src.next) tgt.put(src.tip);
}

Problem is, you won't be able to copy e.g. an int[][] to another because 
the types aren't compatible.

> If you want to mutate though, you require a forward range and use its 
> i.first which must be a reference to the first element in the range.  
> Then you can safely ignore the i.next result which will most likely be a 
> reference to the previous i.first contents.

This part does, I think, work.


Andrei


More information about the Digitalmars-d-announce mailing list