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