[Issue 14478] isInputRange failed to recognize some ranges

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Sure, some may work, but many won't, and a lot of user code out there won't.
Grepping for such usage in Phobos quickly finds some, and a function like
std.array.array _can't_ work with non-copyable elements (and that's a pretty
major range-based function in Phobos).

auto h = r.front;

has been part of the definition of input ranges from the beginning, and so,
everyone has been free to assume that a range's elements are copyable, because
the definition of an input range guarantees it. We can't expect that it won't
break code to change that now - especially when having non-copyable elements is
so rare. This is the first time that I've ever heard anyone complain about this
issue, so it clearly isn't affecting very many people, and the C++ folks
thought that it was okay to require that elements in STL containers be
copyable, so we're not the first to require that sort of thing with a major
component of the standard library.

I can see why you'd want to able to have ranges work with non-copyable
elements, but simply changing the definition of an input range would break too
much code, and I think that it's naive to expect that most range-based code
would work with the change. I've seen plenty of cases in code where something
like

auto value = range.front;

is done, and if this change were made, then that code's template constraints
would be claiming that it worked with non-copyable elements when it didn't, and
as it is now, such template constraints actually guarantee that non-copyable
elements aren't used with such algorithms.

If we were going to support anything like this, then we'd need a new set of
traits for it rather than simply changing isInputRange, and given how rare this
use case is, I don't think that it's worth it. I'd suggest that you just wrap a
would-be range with non-copyable elements in another range which makes it so
that they _are_ copyable (e.g. via pointer) and get around the problem that
way.

--