Re: [boost] [function_types]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-18 16:58:11

Steven Watanabe wrote:
> AMDG
> 
> 
>>Tobias Schwinger wrote:
>>
>>>Now folks complain more about the tags than before. Worse
>>>than that, I haven't been presented a single clearly
>>>superior alternative!
> 
> Because there isn't one?

Maybe. I wouldn't want to claim that while I can neither prove nor disprove it.
I'm just trying to show that the design is reasonable.

> 
>>>Steven Watanabe wrote:
>>>    
>>>
>>>>For both components and the synthesis metafunctions,
>>>>having the result type as the first element of the sequence
>>>>doesn't really make sense to me.  I would expect that
>>>>the return type would often need to be handled separately
>>>>from the parameters in the cases where anything other than
>>>>simply passing the result of components to function_type<...>
>>>>is needed.
>>>>      
>>>
>>>I found it preferable to have a one-type representation,
>>>but I'm currently not feeling to strong about it anymore.
>>>Your proposal might be a good idea -- I'll think about it.
>>>    
> 
> I don't have anything in particular against a one type representation.
> It is probably quite useful. I just don't think giving an mpl
> sequence a special meaning is the right way to do it.

I don't see it this way: a function is a compound type and the mpl sequence contains the component types. They are ordered left to right which seems pretty common, too.

>>>Two things:
>>>
>>>1. How to specify the properties for type synthesis?
>>>
>>>You proposed to strip it out, but I think that the compromising the symmetry of the library is far 
>>>to high of a price for unspecified aesthetical reasons.
>>>    
> 
> If the tags can't be cleanly eliminated from the synthesis
> metafunctions too, then I agree completely.
> I can only think of two ways to do this. 

I'm not sure I understand you correctly, here. To do what? Eliminate the tags? ...

> Neither
> one is completely satisfactory.
> 1.
>   template<class R, class Args, class Option1, class Option2, class Option3>
>   struct function_type :
>     original_function_type<typename mpl::push_front<Args, R>::type, 
> tag<Option1, Option2, Option3> > {};
> 2.
>   template<class ReturnTypeAndArgsAndTagsRolledIntoASingleType>
>   struct function_type : ... {};

... If so, I can't see any "tag elimination"...

> 
> The first may be a little better, but then again it could work
> even with tags--in which case it is just extra syntactic sugar.
> The second one would basically be the inverse of components.
> In the second case a "constructor" for components with signature
> template<class R, class Args, class ... Options>
> would be needed.

... Both alternatives even seem to increase the presence of tags in the interface ...

I considered the first alternative when redesigning the library, but I chose the current design because it doesn't redundantly introduce lots of rarely needed template parameters.

>>2. The primary interface would be "shape shifting" based on the configuration:
>>
>>  is_fastcall_cc
>>  is_stdcall_cc
>>  is_*_cc
>>  
> 
> What about is_same<calling_convention<F>::type, fastcall_cc>?

... Same here: The return type of that metafunction would be a tag again, wouldn't it?
Maybe I just lost track because of a missing sentence or something like that.

Regards,

Tobias