Daniel Walker wrote:
This isn't a bad idea, but I feel that result_of is a simple utility and doesn't merit an additional interface to provide for user extension. Users should simply provide result<>. Boost.Lambda is a special case partially because of long standing precedence and a large user base. It's been around for ages. I like Giovanni's suggestion for transitioning away from sig<> support.
If/when lambda standardizes on result<>, the lambda related special cases in result_of can be removed.
It will break a code using not result_of but sig compatible functors? Apart from politics, I prefer "virtual" to "switch", :-) whether or not the "virtual"(that is, 'extend_result_of') is a public interface.
template<class F, class Arg> void g(F const& f, Arg& x) { typename result_of< F(F, Arg) >::type y = f(x); }
This usage of 'result_of' seems wrong. You meant? typename result_of< F(Arg&) >::type y = f(x);
In the example above where functor f is lambda compatible according to the existing convention, calling f right away causes an error without the result_of patch even though delaying the call to f succeeds with the lambda patch.
Can the patch support a sig compatible functor which is "nullary-callable" (e.g. lambda::constructor<>) ?
On the other hand, "result_of<lambda>" project will be an interesting work. What does "result_of<bind(..)>" return? I want to know it :-)
This is kind of cool! First off, to literally use something like 'result_of<bind(functor)>::type' is illegal. Bind is not a constant expression. result_of requires a function/functor type.
I really want the type, which can be used with result_of. Some considerations will be required.
struct functor { BOOST_FIXED_ARITY_FUNCTOR_RESULT(2, A1)
template<class Arg> typename result<functor(functor, Arg)>::type operator()(Arg const& a) const { return a; } };
I introduce <boost/detail/functionN.hpp> at Boost.Accumulators, which seems very cool. Regards, -- Shunsuke Sogame