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