"David Abrahams" <dave@boost-consulting.com> wrote:
I don't buy the ideas that involve using function types as in
select_overload<int(int)>
because it requires specifying the return type, which is irrelevant.
Current pratice is to speficy the entire signature, including the (irrelevant) return type and the (redundant) class name. Arturo's suggestion gets rid of the return type and class name, but introduces the (irrelevant) arity.
When overloads differ only in the number of parameters and not the parameter types, arity becomes the only thing that's relevant. That's why I thought the ideal use would look like this when that's the case: whatever_cast<1>(&P::f) And like this when it's not: whatever_cast<char>(&P::f) I doubt that's possible though. :(
Using function types eliminates the class name but keeps the return type. So neither is quite right, althought I tend to prefer using function types.
whatever_cast becomes more useful the further away we get from the static_cast form. IMO, the arity-specifying form is further away from that than the function-signature form. Consider that the return type can have a super-long name: whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
The essential information that needs to be supplied is just a typelist. [snip]
Is it possible to implement whatever_cast in such a way that it mimics what mpl::list does - in its acceptance of a variable number of template parameters - but produces a function?