shunsuke wrote:
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".
I don't buy that argument, because to return a tuple, you need to state the return type. If you say the return type is: tuple<int const &> or even: result_of<make_tuple(int const &)>::type ... and you return a tuple containing a reference to a local variable, you get what you asked for: a lot of pain. That's no worse than declaring a function to return an "int const &" and returning a reference to a local. It's not even a problem with the new function declarator syntax in C++0x: auto foo() -> decltype(make_tuple(???)) This can't be made to return a reference to a local variable because no local variables are in scope.
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.
I think your argument is specious.
FWIW, I usually prefer compatibility. :-)
I honestly don't know what the right answer is. I'd like more people to weigh in. -- Eric Niebler Boost Consulting www.boost-consulting.com