Are iterators and ranges going to co-exist?

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 22 14:00:26 PDT 2010


On Thu, 22 Jul 2010 16:13:21 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>>> 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.
>
> I meant iterators, not interfaces. Sorry for the confusion.

OK, sorry for my confusion :)  The unquoted message that you responded to  
made me think you intended to type interfaces was:

"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."

 From my experience with dcollections, implementing cursors in addition to  
ranges is very trivial.  Most node-based container types use "iterators",  
or pointers to elements underneath ranges anyways.  It's generally not an  
extra effort to expose them correctly.  I think cursors solve the safety  
issue quite well.

If you are using duck typing instead of interfaces, it's even easier,  
since you can cover both ranges and cursors with one function (you can  
make a range out of a cursor, or a pair of cursors from a range very  
easily, and then call your implemented function).

Dcollections has a feature where you can swap the underlying  
implementation for something completely different.  The interface between  
the container class and the implementation is some sort of iterator-like  
idiom.  I plan to homogenize this, and make it better documented.   
Hopefully it will become much easier to swap implementations in the future.

-Steve


More information about the Digitalmars-d mailing list