Why are type_traits implemented with specialized template structs instead of constexpr?

Question

Is there any reason why the standard specifies them as template structs instead of simple boolean constexpr?

In an additional question that will probably be answered in a good answer to the main question, how would one do enable_if stuff with the non-struct versions?

Answer 1

One reason is that constexpr functions can't provide a nested type member, which is useful in some meta-programming situations.

To make it clear, I'm not talking only of transformation traits (like make_unsigned) that produce types and obviously can't be made constexpr functions. All type traits provide such a nested type member, even unary type traits and binary type traits. For example is_void<int>::type is false_type.

Of course, this could be worked around with std::integral_constant<bool, the_constexpr_function_version_of_some_trait<T>()>, but it wouldn't be as practical.

In any case, if you really want function-like syntax, that is already possible. You can just use the traits constructor and take advantage of the constexpr implicit conversion in integral_constant:

static_assert(std::is_void<void>(), "void is void; who would have thunk?");

For transformation traits you can use a template alias to obtain something close to that syntax:

template <bool Condition, typename T = void>
using enable_if = typename std::enable_if<Condition, T>::type;
// usage:
// template <typename T> enable_if<is_void<T>(), int> f();
//
// make_unsigned<T> x;

Answer 2

Note: this ends up looking more like a rant than a proper answer... I did got some itch reading the previous answers though, so please excuse me ;)

First, class traits are historically done with template structures because they predate constexpr and decltype. Without those two, it was a bit more work to use functions, though the various library implementations of is_base_of had to use functions internally to get the inheritance right.

What are the advantages of using functions ?

• inheritance just works.
• syntax can be more natural (typename ::type looks stupid ^TM)
• a good number of traits are now obsolete

Actually, inheritance is probably the main point against class traits. It's annoying as hell that you need to specialize all your derived classes to do like momma. Very annoying. With functions you just inherit the traits, and can specialize if you want to.

What are the disadvantages ?

• packaging! A struct trait may embed several types/constants at once.

Of course, one could argue that this is actually annoying: specializing iterator_traits, you just so often gratuitously inherit from std::iterator_traits just to get the default. Different functions would provide this just naturally.

Could it work ?

Well, in a word where everything would be constexpr based, except from enable_if (but then, it's not a trait), you would be going:

template <typename T>
typename enable_if<std::is_integral(T()) and
                   std::is_signed(T())>::type

Note: I did not use std::declval here because it requires an unevaluated context (ie, sizeof or decltype mostly). So one additional requirement (not immediately visible) is that T is default constructible.

If you really want, there is a hack:

#define VALUE_OF(Type_) decltype(std::declval<T>())

template <typename T>
typename enable_if<std::is_integral(VALUE_OF(T)) and
                   std::is_signed(VALUE_OF(T))>::type

And what if I need a type, not a constant ?

decltype(common_type(std::declval<T>(), std::declval<U>()))

I don't see a problem either (and yes, here I use declval). But... passing types has nothing to do with constexpr; constexpr functions are useful when they return values that you are interested in. Functions that return complex types can be used, of course, but they are not constexpr and you don't use the value of the type.

And what if I need to chain trais and types ?

Ironically, this is where functions shine :)

// class version
template <typename Container>
struct iterator { typedef typename Container::iterator type; };

template <typename Container>
struct iterator<Container const> {
  typedef typename Container::const_iterator type;
};

template <typename Container>
struct pointer_type {
  typedef typename iterator<Container>::type::pointer_type type;
};


template <typename Container>
typename pointer_type<Container>::type front(Container& c);

// Here, have a cookie and a glass of milk for reading so far, good boy!
// Don't worry, the worse is behind you.


// function version
template <typename Container>
auto front(Container& c) -> decltype(*begin(c));

What! Cheater! There is no trait defined!

Hum... actually, that's the point. With decltype, a good number of traits have just become redundant.

DRY!

Inheritance just works!

Take a basic class hierarchy:

struct Base {};
struct Derived: Base {};
struct Rederived: Derived {};

And define a trait:

// class version
template <typename T>
struct some_trait: std::false_type {};

template <>
struct some_trait<Base>: std::true_type {};

template <>
struct some_trait<Derived>: some_trait<Base> {}; // to inherit behavior

template <>
struct some_trait<Rederived>: some_trait<Derived> {};

Note: it is intended that the trait for Derived does not state directly true or false but instead take the behavior from its ancestor. This way if the ancestor changes stance, the whole hierarchy follows automatically. Most of the times since the base functionality is provided by the ancestor, it makes sense to follow its trait. Even more so for type traits.

// function version
constexpr bool some_trait(...) { return false; }

constexpr bool some_trait(Base const&) { return true; }

Note: The use of ellipsis is intentional, this is the catch-all overload. A template function would be a better match than the other overloads (no conversion required), whereas the ellipsis is always the worst match guaranteeing it picks up only those for which no other overload is suitable.

I suppose it's unnecessary to precise how more concise the latter approach is ? Not only do you get rid of the template <> clutter, you also get inheritance for free.

Can enable_if be implemented so ?

I don't think so, unfortunately, but as I already said: this is not a trait. And the std version works nicely with constexpr because it uses a bool argument, not a type :)

So Why ?

Well, the only technical reason is that a good portion of the code already relies on a number of traits that was historically provided as types (std::numeric_limit) so consistency would dictate it.

Furthermore it makes migration from boost::is_* just so easier!

I do, personally, think it is unfortunate. But I am probably much more eager to review the existing code I wrote than the average corporation.

Answer 3

One reason is that the type_traits proposal is older than the constexpr proposal.

Another one is that you are allowed to add specializations for your own types, if needed.

Answer 4

Probably because boost already had a version of type_traits that was implemented with templates.

And we all know how much people on the standards committee copy boost.

Answer 5

I would say the mainreason is that type_traits was already part of tr1 and was therefore basically guaranteed to end up in the standard in more or less the same form, so it predates constexpr. Other possible reasons are:

• Having the traits as types allows for overloading functions on the type of the trait
• Many traits (like remove_pointer) define a type instead of a value, so they have to be expressed in this way. Having different interfaces for traits defining values and traits defining types seems unnessecary
• templated structs can be partial specialized, while functions can't, so that might make the implementation of some traits easier

For your second question: As enable_if defines a type (or not, if it is passed false) a nested typedef inside a struct is really the way to go