Re: [boost] [function types] Name changes / synopsis

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-27 08:39:24

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