[Issue 14478] isInputRange failed to recognize some ranges

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14478

--- Comment #12 from Jonathan M Davis <issues.dlang at 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.

--