https://issues.dlang.org/show_bug.cgi?id=14478
--- Comment #8 from Peter Alexander <[email protected]> --- (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. --
