oversight with input ranges

[Atila Neves via Digitalmars-d]

<snip>
> from the very beginning. This isn't new. And given that the C++ 
> STL gets
> away with its containers not working with non-copyable 
> elements, I think
> that that proves that you can have a major component in the 
> standard library
> - containers no less - not support copyable elements and have 
> it work and be
> acceptable.

Semi-acceptable, and even then, no longer the case in C++. Before 
move semantics, yes, C++ containers were limited to copyable 
elements, which meant using raw pointers since auto_ptr couldn't 
be copied. It was a royal pain.

But for 4 years now I've been able to do this:

     std::vector<std::unique_ptr<MyClass>> stuff;
     stuff.emplace_back(new MyClass);
     auto ptr = std::unique_ptr<MyClass>(new MyClass);
     stuff.push_back(std::move(ptr));

Which won't compile with the `std::move` because unique_ptr isn't 
copyable. D has move semantics. C++98/03 did not. The comparison 
with C++ is no longer justified.

Ketmar has a point though. So do you. The worst part of D move 
semantics is not being able to copy a const variable, since 
copying is move + postblit and you can't move from a const object.

Atila