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
