From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-06-09 13:11:13
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