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:
>>>> 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.
> 
> Then I'll continue to think aloud.
[snip]

Thanks for the code samples, they're cool. I hit a problem related to 
the return type of head. Consider writing a range that iterates two 
other ranges in lockstep. A very useful generic range. I started coding 
it like this:

struct Lockstep(R0, R1)
{
     private R0 _r0;
     private R1 _r1;
     this(R0 r0, R1 r1)
     {
        _r0 = r0;
        _r1 = r1;
     }

     bool empty()
     {
         return _r0.empty || _r1.empty;
     }

     Tuple!(ElementType!(R0), ElementType!(R1)) head()
     {
         return tuple(_r0.head, _r1.head);
     }

     void next()
     {
         _r0.next;
         _r1.next;
     }
}

Before long I realized that the type of head was wrong. Along the way, 
the fact that the two ranges return by REFERENCE was irretrivably lost. 
Returning a ref Tuple!(ElementType!(R0), ElementType!(R1)) won't work 
either, because how do you move the references of the _r0.head and 
_r1._head in a common tuple?

The type Tuple!(ref ElementType!(R0), ref ElementType!(R1)) does not 
exist because ref is not a type constructor.

This is quite a pickle because it reveals that ref is not composable. I 
have a few ideas on how to handle this, but I don't want to bias anyone. 
If you have ideas, please fire them up!


Andrei