On Jun 9, 2005, at 12:40 PM, jarvi wrote:
On Jun 9, 2005, at 12:18 PM, Douglas Gregor wrote:
On Jun 9, 2005, at 11:49 AM, David Abrahams wrote:
It seems to me that when BOOST_TYPEOF becomes available, boost::result_of should use it in its default implementation, something like:
template <class F, class A> struct result_of<F(A)> { typedef typename BOOST_TYPEOF(make<F>() ( make<A>() ) ) type; };
Is that in the plan?
Absolutely.
The TR spec says that the implementation can use whatever means to determine the member type type that produces the exact type, and if it cannot determine the exact type, then the specs details out its behavior:
1 If F is a function type, type is the return type of the function type F. 2 If F is a member function type, type is the return type of the member function type F. 3 If F is a function object defined by the standard library, the method of determining type is unspecified. 4 If F is a class type with a member type result_type, type is F::result_type. 5 If F is a class type with no member named result_type or if F::result_type is not a type: a If N=0 (no arguments), type is void. b If N>0, type is F::result<F(T1, T2, ..., TN)>::type. 6 Otherwise, the program is ill-formed.
(Note, this was copy/pasted from the proposal, not from TR1, so the exact rules may now be different).
So if F and A are not registered, then result_of should go and follow the list above?
Yes, that sounds like the right way to handle things. Doug