Proposal: takeFront and takeBack

[Roman D. Boiko]

On Wednesday, 4 July 2012 at 12:24:14 UTC, 
travert at 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.