Ranges and/versus iterators

[Fawzi Mohamed]

On 23-mar-10, at 21:34, Andrei Alexandrescu wrote:

> [...]
> We've discussed this extensively, and I lost sleep over this simple  
> matter more than once. The main problem with bool popFront(ref E) is  
> that it doesn't work meaningfully for containers that expose  
> references to their elements.

yes I agree that it is a difficult problem, the single function works  
well in the basic iterator case, but does not generalize well to  
modifiable values.
In most cases I resorted to returning pointers. The templates that  
generate opApply (still D1.0 ;) from that is smart enough to remove  
the pointer when possible as the ref already gives that.
Still not perfect, as always there are tradeoffs...

> The interface with front() leaves it to the range to return E or ref  
> E.
>
> An alternative is this:
>
> bool empty();
> ref E getNext(); // ref or no ref
>
> I'm thinking seriously of defining input ranges that way. The  
> underlying notion is that you always move forward - getting an  
> element is simultaneous with moving to the next.

already better (for basic iterators), but still not reentrant, if  
another thread executes between empty and getNext...

anyway any choice has some drawbacks... I like bool next(ref T)  
because it works well also for streams... and somehow (using T* or not  
depending on the type) can accommodate all iteration needs.
Not perfectly nice, but workable.

Fawzi