https://issues.dlang.org/show_bug.cgi?id=14478
--- Comment #12 from Jonathan M Davis <issues.dl...@jmdavisprog.com> --- (In reply to Martin Nowak from comment #11) > Algorithms shouldn't needlessly copy values because it might be expensive, > e.g. with big values. > We should probably add an isCopyable!(ElementType!R) to the algorithms that > do require this. Calling front multiple times can be just as expensive (or even more so) depending on what it does - e.g. if it calculates front, that could be more expensive than copying it, or in the case of map, it actually could be allocating a new value for every call to front. So, it's not at all cut and dry as to whether copying front is cheaper or not - especially if the value of front needs to be used multiple times before popFront gets called again. And while I agree that we should avoid unnecessary copying, when the cost of copying has come up in the past, it's pretty much been stated that copying has to be cheap (e.g. IIRC, Andrei always insists that copying should be O(1) - even with postblits - which seems unreasonable to me). So, whether it's a good idea or not, we've generally assumed that copying elements is cheap. The real problem though is that whether it's cheaper to call front once and copy the result or to call it multiple times without copying the result depends on what the range actually does, and there's no way to know. However, given map's behavior in particular, I'd tend to argue that we'd normally want to copy front rather than call it multiple times, which becomes problematic if we then have to worry about whether front is copyable. Some algorithms avoid the problem by only needing to access front once per element, but many of them need to access it multiple times. --