on Sat Jan 26 2013, Joel de Guzman <djowel-AT-gmail.com> wrote:
On 1/26/13 7:58 AM, Dave Abrahams wrote:
I completely agree with the notion that a moved-from object simply should
not be used in any manner.
Well, that's just wrong, for the non-destructive move model used by the standard. The standard library relies on the ability to both assign and destroy moved-from elements. If you want destructive move, that's a whole research project. We on the committee who created rvalue references couldn't figure out how to make it work.
(The) ability to both assign and destroy? Is that all that it needs?
That's all the standard library will use. However, you still have to be honest about the variant's invariant: it must include the moved-from state.
Then we should be OK. A nulled recursive_wrapper can both be assigned and destroyed. It just can't do other things apart from that, such as get the underlying T& and call its member functions.
I am not familiar enough with the details of recursive_wrapper and how much of it is exposed to users to know whether any of this matters. You have to choose: either the addition of this moved-from state must not invalidate any previous guarantees upon which users may rely, OR you have to tell them that you're breaking backward-compatibility and document that the moved-from state is an "anti-precondition" for all the "other things apart from that." Or you could invent a whole new concept of "invariant" that is allowed to be violated... but I really discourage that! :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost