Iterators recap

[Bill Baxter]

Sean Kelly wrote:
> Bill Baxter wrote:
> 
>> Sean Kelly wrote:
>>
>>> Bill Baxter wrote:
>>>
>>>> Sean Kelly wrote:
>>>>
>>>>> Bill Baxter wrote:
>>>>>
>>>>>>
>>>>>> Too bad the iterator discussions fizzled out without anything 
>>>>>> getting decided.
>>>>>
>>>>>
>>>>> I think the design was pretty well settled when things ended.  The 
>>>>> next step would be a sample implementation so folks could wrangle 
>>>>> over syntax.  It's on my "to do" list, but I'm a bit short on free 
>>>>> time at the moment.
>>>>
>>>>
>>>> Huh.  So what is your understanding of what the consensus was?
>>>
>>>
>>> Java-style, with random access iterators overloading array 
>>> operations. I can't remember if there was any clear preference for 
>>> the hasNext/getNext vs. the atEnd/getVal approach, but I tend to 
>>> favor the latter.
>>
>>
>> I like next/value/(ptr) myself.
>> Makes for very succinct while loops.  ptr available where it makes sense.
>>
>> while(iter.next()) {  writefln(iter.value); }
>>
>> while(iter.next()) {  *iter.ptr = 17; }
> 
> 
> It's great for loops, but can be confusing when iterators stick around 
> for a while.  Say I have some code that operates on the current value of 
> an iterator.  With the next() approach, how do I know whether the 
> iterator is valid?  Still, perhaps a hybrid approach is best.  Have next 
> return true on success and offer an atEnd property as well.

Good point.  There's another problem related to iters sitting around a 
while, too, that I hadn't considered.  If you have to call next() to get 
the first item then you'll also need some way to query if the iterator 
is in it's "pre-begin" state.  So the next/atend approach only really 
works when there's no 'value' and 'next' is the only way to get the 
value.  Ick.

So maybe a for-ish way is better than while-ish way:

for (; !iter.end; iter.next) {
     writefln(iter.value);
}

And have iterators start off valid (if not already at the end).


--bb