[result_of] decltype-based result_of cannot handle rvalue-reference correctly

[mimomorin@…]

The implementation of decltype-based boost::result_of is essentially the same as

// This code is taken from N1454 (author: Douglas Gregor)
template <typename F, typename T1, typename T2, ..., typename TN>
class result_of<F(T1, T2, ..., TN)> {
    static F f;
    static T1 t1;
    static T2 t2;
         .
         .
         .
    static TN tN;
    
public:
    // Note: even if Ti is rvalue reference, ti is treated as lvalue.
    typedef decltype(f(t1, t2, ..., tN)) type;
};

So, the implementation cannot handle rvalue-reference correctly (it becomes lvalue).

For example, in the following code

struct func
{
    unsigned char operator()(int&&     ) { return 0; }
      signed char operator()(int&      ) { return 0; }
             char operator()(int const&) { return 0; }
};

boost::result_of<func(int)>::type is signed char (which should be unsigned char).

I will attach a patch for fixing this issue. The patch uses declval rather than static members.

[mimomorin@…]

A patch against trunk (boost/utility/result_of.hpp, boost/utility/detail/result_of_iterate.hpp)

[mimomorin@…]

A patch against trunk (libs/utility/test/result_of_test.cpp)

[mimomorin@…]

Replying to mimomorin@…:

boost::result_of<func(int)>::type is signed char (which should be unsigned char).

This is a typo (though this sentence is still true).

What I meant is:

boost::result_of<func(int&&)>::type is signed char (which should be unsigned char).

[Daniel Walker]

(In [68373]) use declval to fix #5098

[Daniel Walker]

I applied the patches with one modification: instead of defining its own declval, it uses boost::declval. Thanks for input and patches!