Re: [boost] [utility] result_of and lambda patch

From: shunsuke (pstade.mb_at_[hidden])
Date: 2007-03-22 14:18:02

Daniel Walker wrote:
> Plus, as Eric pointed out earlier in this thread, the result_of
> convention of using result<> for return types is now standard (is that
> TR1?). Why shouldn't lambda follow it?

As pointed, lambda should and can follow 'result_of'
by using this way: http://tinyurl.com/2xw4s2
, which will be <boost/lambda/result_of.hpp> or something.
Note that the nullary instantiation seems not special case.

> The third case could be changed to be dependent on the number of
> arguments (after giving the user a chance to supply result_type or
> result<>) if that's preferable. This is simple to implement  with
> has_template_xxx. Am I missing something?

As the rationale states, nullary intantiations of 'result_of'
must always succeed even if the functions are never called.
(Hence, it has the *default* result type -- 'void'.)
Can has_template_xxx detect whether or not
a sig-compatible functor is nullary-callable?

>> I guess a sig-compatible functor which is nullary-callable must be
>> ported to result_of, even if the patch is applied.
> 
> The same is true for a result-compatible functor as described above.
> This is an existing limitation of result_of which we may or may not
> want to address.

If user workarounds of sig-compatible functor users cannot be removed,
that patch loses the original intention?

>> Note that nullary instantiation of 'result_of' must always succeed.
>> (See the rationale at
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html)
> 
> I believe the errors you're seeing are due to the assignment to r
> (which is declared void) and not to result_of<constructor<int>()>
> being ill-formed.

Yes.

>> Well, I have bad news. VC++7.1 and VC8 can't compile (1) nor (2). :-(
> 
> Could you send the error messages you're getting for (1)? (2) won't
> compile due to the limitation that result_of always ignores nullary
> F::result<F()>::type.

has_template_xxx seems not to work.
I tried this:

    typedef char value_type;
    BOOST_MPL_ASSERT((
        has_template_result<
            pair_maker,
            pair_maker(value_type, value_type)
        >
    ));

This assertion fails under VC7.1/VC8.

Regards,

-- 
Shunsuke Sogame