Re: [boost] [function types] New tag type logic [update]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-03 06:14:36

David Abrahams wrote:
> Tobias Schwinger <tschwinger_at_[hidden]> writes:
>>David Abrahams wrote:
>>

<snip>
>>>>>      is_function< T, unspecified_decoration >::value
>>>>>      // true for any type T that the library can handle
>>>>>
>>>>>[You need to say more clearly what "can handle" means.  IMO the
>>>>>comment should really be expressed as the last sentence of the
>>>>>foregoing paragraph]
>>>>
>>>>s/type the library can handle/(possibly decorated) function type/
>>>
>>>
>>>"(possibly decorated)" adds nothing.  You have already made it clear
>>>that function types can be decorated -- or if you haven't, you can't
>>>just throw the term in here in parentheses and expect anyone to
>>>understand what you mean.
>>
>>What 'decorated' means was already introduced (by the very first sentence of the 
>>documentation, see previous post).
>>
>>Generally I agree. However in this case it /should/ be mentioned because:
>>
>>     template<typename T, typename Tag = undecorated> struct is_function;
>>                                         ^^^^^^^^^^^
>>
>>The default argument, if no tag is given, makes 'is_function' only match function
>>types (standard definition, compatible with TypeTraits).
>>
>>The "code-to-English-mapping" is like this:
>>
>>   is_function<T>          // "is T a function (not decorated)?"
>>   is_function<T,pointer>  // "is T a function pointer?"
>>   is_function<T,variadic> // "is the function _in_ T variadic?"
> 
> 
> I am unsure that supporting this default is well-advised.  

Me not either that's why I came to the following conclusion:

Hide the decoration property from the interface and put it in traits classes.

So you only have specify the tag to ask for attributation, such as a particular 
calling convention or whether it is variadic (matching any by default).

     // Result: bool, Concept: MPL-Integral Constant
     template<typename T, typename Tag = no_attributes> struct is_function;
      % %   struct is_function_pointer;
      % %   struct is_function_reference;
      % %   struct is_member_function_pointer;

      % %   struct is_callable_builtin;           // any of the above
      % %   struct is_callable_scalar;            // any except undecorated
      % %   struct is_nonmember_callable_builtin; // any except member pointers
      % %   struct is_nonmember_callable_scalar;  // function pointer or reference

For the full synopsis see: http://lists.boost.org/boost/2005/07/29657.php
Btw. would be awesome if you can afford the time and work to skim over it!

> We already have is_function in the Type Traits library, no?

John and I agreed on that an ultimate goal to make them the same template.
The only question left is whether the mere presence of a default argument hurts.

See also: http://lists.boost.org/boost/2005/06/29297.php

> 
> 
>>However, if too confusing I can introduce a version of 'is_function'
>>with a single template parameter, change the name of the current
>>'is_function' to something else (e.g. "is_function_of_kind" --
>>better names are very welcome) and change its default argument.
> 
> 
>    has_properties?
> 
> I assume you are in some nice nested namespace of Boost, with that suggestion.
> 

Probably not necessary based on what the answer to that question (previous 
paragraph of this post) is.

<snip>
> 
>>   Requirements: one wildcard to match any decoration /or/ to change the default
>>   argument of the class template currently called 'is_function' (as described
>>   above)
> 
> 
> Yes, that would be fine.

Same question here: which one of the two possibilties?

<snip>
>>>>Here the properties of the original types are overridden in an implicit tag
>>>>combination with the tag representing the type.
>>>>
>>>>Well, we /could/ only allow it in this very context, 
>>>
>>>
>>>Allow what?
>>>
>>
>>Sorry: "allow overriding of tag properties".
> 
> 
> I'm lost, sorry.  Too much context is gone.
> 

I explained it again in the longest paragraph of this post: 
http://lists.boost.org/boost/2005/07/29669.php

Thanks,

Tobias