Re: [boost] [function_types]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-20 02:29:36

Richard Smith wrote:
> Tobias Schwinger wrote:
> 
> 
>>Further: none of the reviewers (except Doug Gregor, who
>>was talking about the issue in the very specific context
>>of merger with another library) did answer the following
>>question:
>>
>>   What's wrong with the tag types (other than personal
>>taste) in the first place?
> 
> 
> Having just read your other email, I think I now better
> understand why you want tags -- and why you don't want to go
> the traits route that I suggested.
> 
> What I don't like about the current interface is that it
> seems to use an odd mixture of traits and tags.  Let me try
> to explain.
> 
> The library is supplying an interface to manipulate function
> types (and function pointer, function reference and member
> function pointer types).  The two most obvious parts of a
> function type are the return type and the parameter types.
> These are queried via traits:
> 
>   result_type< Fn >::type
>   mpl::at_c< parameter_types< Fn >, N >::type
> 

> However, on top of this, there are other aspects: calling
> convention and variadic-ness (both of which are probably
> relatively rarely required), and cv-quals for member
> functions (which might be more frequently needed).  

Yeah. But cv-qualification for member functions is usually dealt with in form of a qualified class type. The tags are just needed to overide the default -- and for cv-qualified function types (which by the current standard make a program ill-formed).

> These
> are all handled by the tags mechanism.
> 
>   is_callable_builtin< Fn, variadic >::value
> 
> (I'm assuming that is_callable_builtin returns true for
> functions, references, pointers and members.)
> 
> Finally, there's exactly what sort of function type we're
> dealing with -- function, reference, pointer or member.
> These are handled by separate traits:
> 
>   is_function_reference< Fn >::value
>   is_member_function_pointer< Fn >::value
> 
> That's three (or four if you include the at_c usage to get
> the nth parameter, but let's not go there again) subtly
> different interfaces.  I'm not concerned about the
> difference between ::type and ::value -- as I can put ::type
> in both cases and get a true_type or false_type.
> 
> But that still leaves two different interfaces, which IMO is
> one too many.  My traits suggestion removed one interface by
> ditching the tags, but it wasn't the tag interface that I
> disliked /per se/ -- it was the inconsistency.
> 
> What if you went the other way and used an exclusively
> tag-based interface:
> 
>   namespace bft = boost::function_types;
> 
>   bft::get< int (), result_type >::type
>     // int
> 
>   bft::get< int (), parameter_types >::type
>     // an empty MPL sequence
> 
>   bft::get< void (int*, float), parameter_types >::type
>     // an MPL sequence containing (int*, float)
> 
>   bft::get< void (int*, float), parameter_type<0> >::type
>     // int*    -- optional syntactic sugar
> 
>   bft::get< void (...), is_variadic >::type
>     // true_type
> 
>   bft::get< void (...), is_variadic >::value
>     // true
> 
>   bft::get< void (), is_default_cc >::type
>     // true_type
> 
>   bft::get< void (*)(), is_pointer >::type
>     // true_type
> 
>
> etc...  This is not very dissimilar to the existing
> is_callable_scalar metafunction, but with addition
> is_pointer, is_reference, etc... tags folded in.

I've been there. It's very close to the interface of the previous version.

The descisions towards the current design and against consistency were a matter of practicability: 

<cite from yesterday's post>

I came to the conclusion that simple and straightforward client code is more important -- and it really did cost me quite an effort to let go of the nagging perfectionism about consistency for consistency's sake.

</cite from yesterday's post>

Regards,

Tobias