Proposal: takeFront and takeBack

Christophe Travert travert at phare.normalesup.org
Wed Jul 4 05:24:14 PDT 2012


"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).



More information about the Digitalmars-d mailing list