Re: [boost] [function types] Review

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-06-19 14:59:00

Tobias Schwinger wrote:
> Hi Jonathan,
>

>> Next, function_type_signature is too complex; it has too many
>> members, and their specifications are hard to understand. I would
>> like to see separate metafunctions which take a function type and
>> return
>>
>
> This impression come from the fact that the documentation is
> currently way too weak, especially at this point.
>
> The primary interface of this class template is not to use most of
> these type member and use this class as an MPL Sequence (I'll cite a
> section of previous review discussion, which I hope explains this in
> more detail).
>
> Most of these members are for optimization (saving template
> instantiations) so I vote for efficieny and not putting them into
> wrappers. Even though using the members of 'function_type_signature' directly
> is pretty close to the gory details, I don't think it should be an
> implementation detail.

<snip citation>

I still don't quite understand it. Even if all the work is done by
function_type_signature, can't you give it a more user-friendly interface -- 
perhaps a simple wrapper which hides the 'advanced' members? I will admit I
haven't put a long time into studying 'function_type_signature'; my comments
basically just reflect my impression that 'function_type_signature' is strange
and complex.

>>    1. the sequence of arguments; you might call this
>> function_type::arguments
>
> It already exists and is currently called 'function_type_parameters'.

Okay, sorry I missed it.

> Btw. I prefer the term 'parameter' over 'argument' in this context,
> because a (formal) parameter constraints the argument (which is also
> called an actual parameter). I.e. (translated Standardese) the
> argument is what is passed for a parameter.
> I know e.g. 'std::unary_function::argument_type' -- but this is not
> exactly the same (I interpret it like: "please give me an argument of
> this type").

I, too, try to maintain the distinction between parameters and arguments. I'm
not sure it's decisive here, though, since I usually think of a parameter as
comprising a type *and* a formal name.

>>    2. the sequence of arguments, including ant implicit 'this'
>> pointer; you might call this function_type::effective_arguments
>
> I've been thinking about this too already... This functionaliy has
> been
> requested by David Abrahams, already.

>> Alternatively, the result of instantiating the templates might
>> themselves be sequences.
>
> It's like this, already. You can either use e.g:
>
>      mpl::at< function_type_parameter<T>, I >
>      mpl::at< function_type_signature<T>, I >

I understand; I was just saying that I thought function_type_signature was too
complicated, and listing the functionality that I thought should be available
one way or another.

>> Next, it's too hard too keep track of all the different tags, esp.
>> remembering the order of the components of the names. Why not have a
>> few atomic tags, and
>
> I like the idea of atomic tags to query aspects instead of full
> combinations...
>
>> let user's combine them via inheritance? E.g.,
>>
>>     struct const_tag { };
>>     struct volatile_tag { };
>>     struct reference_tag { };
>>     struct variadic_tag { };
>>     struct stdcall_tag { };
>>
>>     struct my_tag :
>>          reference_tag,
>>          stdcall_tag,
>>          ...
>>        { };
>
> ..making this work with inheritance, in particular, might be
> inefficient. though (internally these are just MPL Integral Constant
> bit masks).

It involves an extra level of indirection. However, I think it could be done in
a way that adds only a miniscule amount of compile time when using the built-in
tags.

>>    typedef is_function_type<my_tag, T>::type result;
>>
>
>> You could define a bunch of convenience tags for common cases, but
>> people wouldn't be required to learn them. This is what the
>> iostreams library does.
>
> This is a bit opposite to the suggestion to remove the dominant role
> of tags...

I don't see how this is opposite.

Jonathan