RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> The other problem with empty is that it doesn't generalize to what I
> happen think a bidirectional range should be, one with .next .prev,
> .hasNext and .hasPrev.

hasNext and hasPrev are not orthogonal and add unnecessarily 
complicated. Is there a range that has next but not prev, or vice versa? 
No, Sir. There is an "there's still meat on the plate" condition and 
that's all needed.

> Your bidir iterator in C++ parlance is a forward iterator and a
> reverse iterator operating on the same sequence.  I can't really think
> of any algorithms other than the one you showed that use such a pair.
 >
> On the other hand my bidir is useful in all the places a C++ bidir
> iterator is useful.  Any time you need to scan a cursor back and
> forth.  It basically maps directly onto the operation a doubly-linked
> list is good at.  But could be used in traversing any tree-like data
> structure too, I think.

--it is easily done with range primitives if you've saved the initial 
position of it.

>>> Similarly, using list terminology led you to "pop".  But pop on a
>>> range does not actually remove any content.  Pop just moves the goal
>>> post on one end.
>> Correct. Then how would you name'em?

r.atEnd
r.value
r.next
r.moveTo(s)
r.moveToEndOf(s)
r.last
r.pop
r.moveEndToEndOf(s) / moveEndTo(s)

I see in another post:

r.atStart

which I think is a design faux pas. Aside from that, things seem 
workable. But honestly I don't see how they bring a world of difference, 
nor had I a slap on my forehead moment when seeing the primitive names 
(as I did with before and after).


Andrei