Re: [boost] boost::result_of and C++03

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-04-09 22:11:21

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