Proposal: takeFront and takeBack

[Roman D. Boiko]

On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
> I do agree with that. However, the current proposal have the 
> same drawback but on the code that use the range.
>
> Both solutions are messy IMO.

What is error-prone in current client code?

If particular algorithm wants to take advantage of a potential 
speed-up, it may decide to check whether hasConsume!Range, and 
call consumeFront instead of front + popFront. Nobody is obliged 
to do so.

The only problem I can see is potential code duplication, which 
is lower priority in performance-critical part of code, IMO.