Iterators for D

[Bill Baxter]

Walter Bright wrote:
> Sean Kelly wrote:
>> Since D has slicing, the argument for using iterators to define the 
>> boundaries of a range of randomly accessible elements seems kind of 
>> small to me.  ie.
>>
>>     sort( a.begin, a.begin + 5 ); // sort the first 5 elements
>> or
>>     sort( a[0 .. 5] );
>>
>> I find the second to be cleaner to look at.  But I'm undecided whether 
>> we'd lose any power or flexibility by not bothering with random access 
>> iterators.
> 
> Hmm, instead of 'pointers as iterators', have 'arrays as iterators'. 
> That definitely sounds like a good area to explore.

OOh, I like the direction this is heading.

Sean I don't have time to read the straw-man right now but that 
definitely solves my recursive mergesort question.

And Benji's comment about simple iterators and ranges being distinct 
things that shouldn't be lumped together also seems on target.  If 
iterators don't have to be ranges then it's simple to see how to support 
iterators over infinite or circular containers.  They just never stop 
spitting out 'next()'s

But how do you handle generically pointing to an element then?  Like you 
have with an iterator to a node in linked list.  I guess you can have 
iterators with hasPrev() getPrev() (or --) type methods too.

--bb