Peter Dimov wrote:
Eric Niebler:
Peter Dimov wrote:
Eric Niebler:
I'm glad we know how to write the identity function object in C++0x. What about in C++03? I'd put the C++03 overloads in an #else block; apart from that, this identity function object is correct. OK, thanks. Just for my own understanding, leaving the C++03 overloads in -- as well as the nested result<> template -- doesn't make it wrong, correct? Just not minimal.
Doesn't the Arg& overload lead to an ambiguity? The Arg const& overload looks harmless. I don't have an && compiler handy at the moment to check it though. :-)
I just tried, and it looks like you're right. Non-const lvalues can match the Arg& or the Arg&& overload. I find that a little surprising. Anyway, about the rvalue_wrapper<> Shunsuke proposed and I just endorsed. The issue is that today, users are writing code like this: int const i = 0; fusion::tuple<int> t = fusion::make_tuple(i); This is arguably wrong because it is storing an lvalue by value. This is probably more correct: int const i = 0; fusion::tuple<int const &> t = fusion::make_tuple(i); In C++0x, it will be very easy to get this more correct behavior. Will we change our functions (and function objects) then? Even if it breaks users' code? The alternative is to assume that T const & really means lvalue. And when you pass an rvalue you do it like this: fusion::tuple<int> t = fusion::make_tuple(rvalue(1)); But then we have to live with this nightmare until C++0x arrives: // ouch! fusion::tuple<int const &> t = fusion::make_tuple(1); Yikes. Now I'm not sure. Safety or forward compatibility? Looks like we can't have them both. :-/ -- Eric Niebler Boost Consulting www.boost-consulting.com