dan marsden wrote:
The definition of Fusion polymorphic function object will be changed shortly to be consistent with boost.resultof. Instead of requiring a nested result metafunction of the form:
template<typename T0, typename T1, ... typename TN> struct result { typedef xxx type; };
A polymorphic function object will instead simply be required to suppport
boost::result_of<F(A,B,...Z)>::type
as a valid expression.
This will break some Fusion client code, specifically, if you are using fold, accumulate, transform, or a lot of the components in the functional section of the library, you may need to make changes to support this change.
The change should be entered into CVS head over the forthcoming weekend.
Apologies to anyone whos code this breaks, but this should make things more consistent with the rest of boost going forwards.
Thanks Dan! (CC'ing Doug) Doug, I know the result_of interface is almost standard now, but I still wonder about the redundancy of the function-object interface: F::result<F(T1, T2,..., TN)>::type Is there a rationale? F is redundant here. The former fusion result API does not require the F. Now, for example, instead of writing: struct square { template<typename T> struct result { typedef int type; }; template <typename T> int operator()(T x) const { return x * x; } }; We have to write it as: struct square { template<typename T> struct result; template <typename T> struct result<square(T)> { typedef int type; }; template <typename T> int operator()(T x) const { return x * x; } }; I'm not complaining, we already bit the conformance bullet :P Just wondering why the latter is superior to the former. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net