On Feb 9, 2004, at 9:44 AM, David Abrahams wrote:
One thing I think we overlooked in the move proposal, though, is the fact that "only movable and not copyable" class rvalues *still* can't legally be passed where a const reference is expected, unless the rule in question is lifted. That seems like a problem to me.
I'm not sure I'm completely following, but let me try... Given: class A { public: A(); A(A&&); ~A(); private: A(const A&); A& operator=(const A&); }; (or perhaps more elegantly: explicit class A { public: A(); A(A&&); ~A(); }; :-) ) and void foo(const A&); then the problem is: foo(A()); ? Problem because 12.1 requires an accessible copy ctor even if the temp is elided? I don't think this is a problem with the move proposal (of course 12.1 would probably need to be clarified with the introduction of the rvalue reference). Reasoning: foo(A()); expands to: foo(A(A())); i.e. a temporary copy is at least conceptually created and then that is bound to the const A&. In order to create the temporary copy, name lookup finds two possible signatures to create the copy: A(A&&); A(const A&); Since the argument is an rvalue, the accessible A(A&&) is chosen over the inaccessible A(const A&), and so I see no problem. Now the extra temporary can be elided, and in that case the original temporary is bound to foo's parameter. Or, if the extra temporary is not elided, then the original temporary is used to move construct another temporary which in turn is bound to foo's parameter. Either way, the result is the same (except for efficiency issues of move constructing an extra temporary), and the process is consistent with our existing process. Or have I completely missed your point? -Howard