On Wednesday, 4 July 2012 at 12:24:14 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I am not sure what would be worse, in the long run, between
asking developpers to make front remain valid after popFront
until next call to front, or having two different standard ways
to iterate an input range (front/popFront and consumeFront).
Just to clarify (although I gave up with that idea):
my suggestion was not to require that value returned from front
was valid until next call to front. It was the following:
in those ranges where value returned from front is invalidated
after a call to popFront, define consumeFront in a such way that
an equivalent of popFront is deferred until the next call to any
of [front, popFront, consumeFront], and make empty take into
account information whether popFront is pending.
Currently I think that idea was very bad, given that it would be
difficult to find all ranges which invalidate previous front
value on popFront.
