On Tuesday, 3 July 2012 at 18:12:54 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
Range have been designed with the idea that front is valid
until next
call to popFront. If popFront was to be called right after
front, then
it would just be a popFront that returns a value, and maybe a
justPop or
something if you don't want to copy the value.
It's delicate to come now and decide that if a previously
returned front
value is no longer valid after a call to popFront, it should be
documented by an enum. Who is going to review all libraries
(written and
to come) to make sure the enum is placed when it should be? The
reverse
should be done instead: if you want you range to be optimized
by calling
takeFront, define something (for example... takeFront). Then use
algorithms that are specialized for takeFront.
takeFront -> consumeFront
hasConsume has been proposed by Jonathan already.
But not having to modify all existing ranges which invalidate
value returned by front might be a good argument against my hack
also.
However I'm not sure there are really many of such ranges. Those
must return something with reference semantics in order to be
able to invalidate it. Most common case would be when front value
is always stored in the same memory (a buffer).
The benefit of my hacking idea is that clients would need no
special casing.
