<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
