RFC on range design for D2

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Thu, Sep 11, 2008 at 9:32 AM, Bill Baxter <wbaxter at gmail.com> wrote:
>> On Thu, Sep 11, 2008 at 8:17 AM, Steven Schveighoffer
>>> To get the value there, I have to do:
>>> all.after(center).left // or whatever gets decided as the 'get first 
>>> value
>>> of range' member
>>> or if opStar is used:
>>>
>>> *all.after(center);
>>
>> Why is all that necessary?  Can't you just do a  *center?
>
> Oh, I get it.  It's empty.  Duh.
>
> Ok, so you can have third cursor function in the std lib:
>
> T cursorValue(R,T)(R all, R center)
> {
>   return all.after(center).left;
> }
> ... plus the
> cursorAdvance and cursorRetreat.

That is all fine and dandy in the world of "I don't care how well my 
iterators perform or how much code bloat is added because of them," but I 
usually work in a different world ;)

But if I were forced not to use an iterator model (which isn't the case, 
iterators should be very possible without compiler help), I would actually 
implement this as a wrapper struct:

struct Cursor(containerType)
{
   private Range!(containerType) _cur;
   private containerType owner;

   Cursor  moveLeft() {...}
   Cursor moveRight() {...}
   bool hasLeft() {...}
   etc.
}

Thus one can implement iterators on top of ranges, but I'd argue that ranges 
are much easier to implement on top of iterators.

In any case, I think there are benefits to having a range type that is not 
necessarily defined as two iterators.

-Steve