[Issue 14478] isInputRange failed to recognize some ranges

[via Digitalmars-d-bugs]

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

--- Comment #8 from Peter Alexander <peter.alexander.au at gmail.com> ---
(In reply to Jonathan M Davis from comment #7)
> > Most containers in C++ only require movability, otherwise you couldn't have containers of std::unique_ptr<T>
> 
> Then that's a change with C++11.

Correct. Move semantics didn't really exist before C++11.


> Regardless, while it might be nice to support non-copyable elements with
> ranges, I really don't think that it's worth it - particularly when
> isInputRange has always required copyability. We'd be forced to either
> create a separate set of basic range traits - e.g.
> isInputRangeWithNonCopyableElements - or add something like
> hasCopyableElements and change isInputRange to no longer require copyable
> elements, which would then mean that a large portion of the range-based code
> out there would be wrong, since a lot of it is going to be copying elements,
> and unless folks regularly test their range-based code with ranges with
> non-copyable elements, they're not likely to catch the bugs where they
> accidentally require it, and they could be in for some rude surprises later
> when someone tries to use non-copyable elements. We already have enough
> problems with code assuming forward ranges or assuming that ranges aren't
> full reference types, which cause all kinds of fun bugs - including in
> Phobos.

I'd propose your second options: we already have hasMobileElements,
hasAssignableElements etc., so I see no harm adding hasCopyableElements, and
relax the isInputRange restrictions.

Worst case scenario: someone has a range algorithm that expects copyable
elements, but doesn't test for it, and tries to use it with move-only elements.
In this case, they'll get an error on the line that tries to do the copy.

Other than that, I don't believe any existing code will break.

--