Re: [boost] [function types] Review

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 15:03:18

Tobias Schwinger wrote:
> Hi Jonathan,
> 
> Jonathan Turkanis wrote:
> 
>>Hi,
>>
>>Here's my review of the function types submission. I'm sorry I waited until the
>>last minute to submit my review.
>>
>>I vote to accept the library, even though I have some problems with the design.
>>
> 
> 
> Thank you for your review and for the positive vote.
> 
> 
>>>What is your evaluation of the design?
>>
>>
>>My main criticism is that the metafunctions taking tags are given too prominent
>>a place in the library. I would rather have the library provide a collection
>>metafunctions to handle the most common combinations of tags and provide the
>>more generic metafunctions for 'advanced' use.
>>
>>For example, I'd like to have metafunctions 'is_[plain_]function_type,'
>>'is_function_pointer,' 'is_function_reference' and
>>'is_const_member_function_pointer,' like I provided in the above mentioned
>>library, in addition to 'is_function_type.' Also, I'd like to see specialized
>>metafunctions for constructing (plain) function types, function pointers and
>>function references, in addition to the general purpose metafunction
>>'function_type.'
> 
> 
> Basically a set of wrappers... I like it, especially in conjunction with Dave's 
> request to put things into a sub namespace of boost. These expressive forms 
> could go into boost (given they don't collide with TypeTraits) then.
> 
> 

Some more thoughts on this:

Having this sort of interface, I'ld like to put the tag after the other 
parameter for the "advanced" functions taking a tag.

The "metafunctions for most common cases" (as proposed in the review) can be 
implemented directly (rather than wrapping is_function_type) to save a template 
instantiation, of course.

These would be candidates to be merged with TypeTraits. Something like this:

     // Pseudo code
     #if BOOST_FT_CLASSIFICATION_WORKS_ON_CURRENT_COMPILER
     using boost::function_types::is_member_function_pointer // for example
     #else
     // highly portable code
     #endif

would allow a smooth transistion.

I'm not really sure on the "fine grained metafunctions for type synthesis" part 
of your suggestion, though. It's a pretty "advanced" use case, isn't it?
Putting the tag at the end of the template parameter list allows a default 
parameter like 'plain_function', so we wouldn't need a tag in most cases:

     function_type<Sig>::type
     function_type<Sig>::type &
     function_type<Sig>::type *

Comments welcome!

Regards,

Tobias