Eric Niebler wrote:
David Abrahams wrote:
I'm letting users opt-in with reference_wrapper. I understand that's the scope you chose. I was only trying to explore whether that facility can usefully be pushed a little further so that we don't lose move semantics inside of forwarded arguments. Well, I guess we don't, if we assume everything's an rvalue by default :-) I'm not sure if changes are needed to better support move semantics, or what they would be. Feedback is welcome.
Basically, if your wrappers copy arguments by default,
They don't. They could, but I don't think they should, do you?
I'm not entirely sure
then it's always safe for wrapped functions to move from arguments unless they are reference_wrappers. We could even make move(x) where x is a reference_wrapper return an lvalue, so it'd be transparent.
I'm not seeing a win here, at least not for C++03. Little help?
One of the motivations for perfect forwarding in C++0x is that a forwarding function that simply turns everything into lvalues when it presents the arguments to the forwarded-to function kills most opportunities for move semantics (since the main opportunities arise with non-const rvalues). If we start supporting move semantics in Boost, it would be nice if our forwarding functions could avoid turning non-const rvalueness into some kind of lvalueness. -- Dave Abrahams BoostPro Computing http://www.boostpro.com