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