John Maddock wrote:
Synopsis:
Mostly look good to me!
namespace boost { namespace function_type { // Result: bool, Concept: MPL-Integral Constant template<typename T, typename QueryTag = undecorated> struct is_function_;
I don't like the trailing underscore much, but I see why it's there :-)
Me not either ;-).
On the other hand, since we're in a separate namespace from type_traits we could just drop the underscore... might lead to confusion though. Come to that having the underscore will lead to confusion as well IMO.
I understand why you dropped the trailing "_type" suffix, but "is_function_type" was the only obvious alternative I could think of.
Hmmm, how about "is_function_kind" ? Not pretty, but it kind of sums up what the meta-function does.
'is_function_of_kind' perhaps -- see below.
Any other ideas anyone?
Let's just drop the underscore -- see below. Btw. the cv tags will imply 'member_pointer' decoration, so I can call them 'const_member' and 'volatile_member' instead of 'const_' and 'volatile_' respectively. No trailing underscores left then...
// Result: bool, Concept: MPL-Integral Constant template<typename T> struct is_function_pointer; template<typename T> struct is_function_reference; template<typename T> struct is_member_function_pointer_;
I think the trailing underscore has to go from there as well IMO. Ideally this one and the type traits one should be the same template. They have the same semantics don't they?
They have the same semantics, except is_function which /defaults/ to it. If this is a problem we can split off 'is_function_of_kind<T,Tag>' from 'is_function<T>'. The long-term plan is to make 'is_function' and 'is_member_function_pointer' the same templates as in Type Traits -- and since this may depend on the compiler, having no underscore has this advantage: // inside type_traits #if FUNCTION_TYPE_SUPPORTS_CURRENT_COMPILER using ::boost::function_type::$name; #else // highly portable implementation of $name #endif
While we're at it, can the traits inherit from boost::integral_constant<bool, true/false> please? They will still be MPL friendly, and they'll follow the type_traits and TR1 conceptual framework as well then
Sure. I'll generate similar code as type_traits/detail/bool_trait_def.hpp does.
The rest of the synopsis looks good to me.
Thanks, Tobias