Why should I use Boost.CallableTraits?

If you are not writing generic code, you should not use Boost.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 & noexcept> {
    //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
};

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

Boost.CallableTraits is thoroughly tested on many platforms. Boost.CallableTraits correctly handles many corner cases that are often overlooked. The need for a proper library solution grows as more features are added to C++.

Boost is a massive dependency. Do I really need it?

Nope! Boost.CallableTraits doesn't have any dependencies, so all you need are the Boost.CallableTraits headers.

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

Boost contains a handful of excellent type containers. However, Boost.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. This also parallels the metafunctions provided in <type_traits>.

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.

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.