Re: [boost] [typeof][result_of] Separated at Birth?

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