"Roman D. Boiko" , dans le message (digitalmars.D:171108), a écrit : > > 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 can do that in your own code if you think it is critical. Code-duplicating phobos and other libraries to make everyone take advantage of that may be a good intent, but I am afraid the cost in code maintenance may overcomes the performance gain. 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).