AMDG Sorry for taking so long to reply. Tobias Schwinger wrote:
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.
OK. I understand now. I had this kind of thing in mind: function_type< mpl::push_front< result_type<F>::type, mpl::push_front<parameter_types<F>::type, int>::type >::type
::type The outer push_front doesn't express the intent of the code clearly.
The mpl sequence is fine if it is just going to be created on the spot like: function_type<mpl::vector<int, bool, char> >::type For these cases what you have is as good as anything.
I'm not sure I understand you correctly, here. To do what? Eliminate the tags? ... I suppose I should have been more clear. The thing I object to is tag<...> not the individual tags. I don't see any way out of using a type to represent the calling convention anyway.
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"... ... 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.
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
Suppose I want to change a function's calling convention. function_type<components<int(...)>, tag<components<int(...)>, stdcall_cc> >::type This is awkward even if the function to be modified is simple. If on the other hand it is needed for a computed function type where typedef is impossible e.g. a function declaration.... I believe this is one of the reasons MPL chose to pass containers to algorithms instead of iterator pairs. Now, about actually removing tags. How often are the cv tags likely to be used? They are redundant since for member functions this information is already available in the first parameter. If they are not a very common thing to need, I would propose simply removing them from the interface. If you stick to the MPL sequence representation, what about adding the variable argument list onto the end? function_type<mpl::vector<int, int, varargs> >::type that way it looks more like the actual function type. In Christ, Steven Watanabe