Revised RFC on range design for D2

[Andrei Alexandrescu]

Sergey Gromov wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
>> 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 Src is an input range you must make a deep copy.  This holds true for 
> your current design also.  So this algorithm is flawed and it's good if 
> it won't compile.

Great point. I need to sleep on this some more.

> I don't know how to make a generic deep copy, but I believe your meta-fu 
> is much stronger than mine, so I'll leave it to you.  ;)

It is doable, and if not, Walter will make it so :o).


Andrei