On Jul 8, 2004, at 11:10 AM, David Abrahams wrote:
Are there really any repercussions from making a noncopyable type into a moveable type, other than that you might want to find ways to take advantage of the new moveability?
If I had an rvalue reference available today, I would design the interface of the read and write locks differently. For example, instead of: void f(rw_mutex& m) { rw_mutex::upgradable_read_lock r(m); if (...) { rw_mutex::write_lock w(r); //... w.transfer_to(r); } //Point A } I would propose: void f(rw_mutex& m) { rw_mutex::upgradable_read_lock r(m); if (...) { rw_mutex::write_lock w(move(r)); //... r = move(w); } //Point A } The original code would not compile: write_lock would not accept an lvalue upgradable_read_lock and transfer_to would not exist. This would allow, among other things, locks to be returned from functions (as long as they were auto-local within the function). It would also allow for containers of locks. So the major repercussion that I see is that we're designing an inferior interface today that is not forward compatible with what I would propose if move semantics were available. We could possibly fake the desired move syntax today, but the thought makes me tired. :-( Especially in the light that the proposed move syntax is by no means a sure deal. -Howard