Eric Niebler wrote:
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);
It seems to depend on context or domain. Proto may expect it, but int const i = 0; return fusion::make_tuple(i); would be "ouch". BTW, Egg offers "pack", which captures all the arguments by-reference.
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.
:-/
As shown above, lvalue/rvalue-ness doesn't guarantee the complete safety. FWIW, I usually prefer compatibility. :-) Regards, -- Shunsuke Sogame