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

From: Eric Niebler (eric_at_[hidden])
Date: 2008-04-10 00:53:38

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