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.
