RFC on range design for D2

[Bill Baxter]

On Thu, Sep 11, 2008 at 1:30 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> However a range isn't, generally speaking, a list.  It's a way to
>> traverse or access data that may or may not be a list.  For something
>> like an unbounded generator, it is odd to speak of the "first".  Such
>> an object has a current value and a "next", but the value you can look
>> at right now is only the "first" by a bit of a terminology stretch.
>
> Agreed. The problem with "current" instead of "first" is that there's no
> clear correspondent for "the last that the current will be". First and last
> are obvious. Current and last are... well, not bad either :o).
>
>> I think using list terminology unnecessarily confuses the iterating
>> construct that does the accessing with the container being accessed.
>> The range is not the container.  The range consists of a place where
>> you are, and a termination condition.
>
> No. A bidirectional range also knows the last place you'll ever be, and is
> able to manipulate it.

That's just a mutable termination condition.  Still fits my description.

>>  The range is not "empty" or
>> "full" because it does not actually contain elements.
>
> It is because a range is a view. The view can reduce to nothing. In math, an
> interval can be "empty". That doesn't mean it made all real numbers
> disappear :o).

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.

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.

>> 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?

I made one proposal on digitalmars.D and I'm still waiting for comments.

>> And then there's the various union/diff stuff, which everyone seems to
>> find confusing.  I think much of that confusion and mental overhead
>> just goes away if you think of a range as a good old iterator plus a
>> stopping condition.
>
> I like before and after. Besides, the challenge is that you come with
> something that's not confusing.

Yeh, before and after aren't too bad.

>>> Names for the before and after range operations are still in the air...
>>>
>>> Are you referring to the "range" name itself?
>>
>> That could be part of the reason for this tendency to try to assign
>> list-like names to the parts.  If it were called a "bounded iterator"
>> I think that would better describe the perspective I'm pushing, and
>> naturally lead to choices like "atEnd" instead of "isEmpty".
>
> Words are powerful. Phrases are less powerful. I'll never ever settle on
> anything longer than ONE word for the concept. Ranges came to mind because
> boost uses them with a similar meaning.

Yeh, I don't really have a problem with calling them ranges, as long
as people keep in mind they're really bounded iterators.  :-)

--bb