Proposal: takeFront and takeBack

[deadalnix]

Le 04/07/2012 13:04, Roman D. Boiko a écrit :
> 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.
>

You have to maintain 2 version of you algorithm. This is more work to 
test, to maintain, and it is likely to introduce more bugs.

More code == more bugs. More NPATH = more bugs and harder to test and to 
maintain.

In addition, this will result in practice in less generic code, because 
one may not need the version of the algorithm without consume primitives 
in his/her own code and not code it at all.