Revised RFC on range design for D2

[Sergey Gromov]

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.

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.  ;)