Proposal: takeFront and takeBack

[Roman D. Boiko]

On Tuesday, 3 July 2012 at 18:12:54 UTC, 
travert at 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.