Are iterators and ranges going to co-exist?

[Steven Schveighoffer]

On Wed, 21 Jul 2010 23:56:20 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Peter Alexander wrote:
>> == Quote from Walter Bright (newshound2 at digitalmars.com)'s article
>>> If some algorithms used ranges and others used iterators, the
>> poor programmer
>>> would find himself then obliged to implement both interfaces for
>> each container.
>>  This makes no sense.
>>  I don't understand why you see ranges and iterators as conflicting
>> concepts. The cursors/iterators are for referring to individual
>> elements, and ranges are for specifying iterations over a sequence.
>
> Right, so the container programmer is obliged to implement both.

With std.container, nobody is obliged to implement anything.  If you look  
at the model, everything is referred to as Stuff, which can be anything.

To further this point, SList accepts *two* types of ranges, a normal SList  
range, and a Take!(Slist.Range) range.  Really, a cursor is a Take range  
of length 1, so it's not a big leap to add such ranges.

Also note that typically, "supporting another range type" can be as easy  
as adding another branch to the template constraint if statement.

>> There aren't two competing interfaces here. If your interface
>> requires a range of elements, you use a range. If it only needs a
>> single element, you use a cursor.
>
> The algorithm is the one doing the requiring, not the container. So, if  
> there are standard algorithms some of which require ranges and others  
> that require interfaces, the container implementor is obliged to provide  
> both.

Now you are just misinterpreting :)  Nobody said anything about D  
interfaces.

And ranges are supersets of cursors.  All ranges of containers can provide  
a cursor of the front element.  All dcollections ranges provide both begin  
and end cursors, so if you have a range and you need a cursor, it's just  
an accessor.

>>>> All I would like to see is some way to generically point to a
>>>> single element in a range.
>>> range[0] ?
>> That only works on arrays, therefore it is not generic.
>
> Any range can provide a [0] interface.

First, that is patently incorrect.  You cannot provide a [0] interface,  
you can only provide a [int] interface.  Which means you must throw on all  
values other than 0, and that is absolutely appalling.

Second, when he says point to a single element, he doesn't mean point to  
any element picked by the container, he means point to a *specific*  
element.  For example, he may want a pointer to the second element.

>>> There is the massive unsafeness of using iterators. We'd like
>> the whole of the
>>> algorithms to be guaranteed memory safe, and that cannot happen
>> with iterators.
>>> Being able to statically guarantee memory safety is a huge deal,
>> and the larger
>>> a program is and the larger the team working on it, the more
>> this matters.
>>  The iterators would not need to be used for iterations.
>
> Perhaps calling them iterators, then, is a source of confusion!

Yeah, dcollections changed iterators to cursor early on to avoid the  
confusion with C++ iterators, which they are not.

-Steve