Why should I use CallableTraits?

If you are not writing generic code, you should not use CallableTraits.

If you are writing generic code, take a moment to skim your header files, and see if you can find code that looks like this:

template<class Return, class First, class Second>
class foo<Return(First, Second)> {
    //     ^^^^^^^^^^^^^^^^^^^^^
};

Or maybe something like this:

template<class Return, class ...Args>
class foo<Return(*)(Args...)> {
    //     ^^^^^^^^^^^^^^^^^^
    //...
};

Or, if you are really unlucky, something like this:

template<class Return, class T, class ...Args>
class foo<Return(T::*)(Args..., ...) const volatile && transaction_safe> {
    //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    //...
};

With CallableTraits, you can get rid of all of these template specializations (unless you deal with platform-specific calling conventions). Even if you are only specializing a simple function type like Return(Args...), CallableTraits might be useful to you. You may find that CallableTraits can help make your code more readable, more maintainable, more generic, and less error-prone.

Why should I use this instead of this 30 line header I wrote 10 years ago?

CallableTraits is very thoroughly tested on many platforms. CallableTraits correctly handles many corner cases that are often overlooked. The need for a proper library solution grows as more and more features area added to C++. Eventually, I will submit a proposal for CallableTraits features to the ISO C++20 standards committee.

Why does boost::callable_traits::args_t alias a std::tuple instead of X?

Boost contains a handful of excellent type containers. However, CallableTraits is designed to only use the standard headers, so <tuple> was the only option under this limitation. It would be trivial to support other variadic containers, and I will consider doing so if there is sufficient interest.

Why use reference collapsing rules when adding member function ref-qualifiers?

Although arbitrary, the reference collapsing rules are well-defined and already known to many template metaprogrammers. Anything else would be a burden to memorize.

How is this a C++11 library if it uses newer features like variable templates?

If your compiler doesn't support a certain language feature that is required by a metafunction, the implementation will either trigger a static_assert or a substitution failure, depending on the situation. This is explained in the "Compatibility Notes" section for each trait.

Many features in this library cause a "substitution failure" when the template constraints are violated. Does this mean that I can violate the constraints in a SFINAE context, as long as there is another legal substitute?

Yes. The SFINAE-ability of violated constraints has been tested extensively on all compilers. Achieving this required some messy code in the public header files.

I see that arg_at is defined in terms of arg_at_t. Shouldn't it be the other way around?

Alias templates are much more friendly to SFINAE. The struct-style metafunctions are provided only to parallel the <type_traits> naming conventions.

What about calling conventions?

I originally implemented features for these. However, these features necessitated many, many more platform-specific test cases than I was willing to write for a version 1.0 release. The code is still designed to accommodate such features, so I would consider adding them in the future if there is sufficient interest.