Question

Similar question: Why are type_traits implemented with specialized template structs instead of constexpr? – but with a different answer.

I realise that alias templates cannot be specialised and hence can’t currently be used to implement type traits directly¹. However, this is a conscious decision of the committee, and as far as I see there is no technical reason to forbid this.

So wouldn’t it have made more sense to implement type traits as alias templates, streamlining their syntax?

Consider

 typename enable_if<is_pointer<T>::value, size_t>::type
 address(T p);

versus

 enable_if<is_pointer<T>, size_t> address(T p);

Of course, this introduces a breaking interface change when moving from Boost.TypeTraits – but is this really such a big problem?

After all, the code will need to be modified anyway since the types reside in different namespace and, as many modern C++ programmers are reluctant to open namespaces, will be qualified explicitly (if it would be changed at all).

On the other hand, it vastly simplifies the code. And given that template metaprogramming often gets deeply nested, convoluted and complex, it seems obvious that a clearer interface is beneficial.

Am I missing something? If not, I’d appreciate an answer that is not mere guesswork but relies on (and can cite) knowledge of the committee’s decision rationale.

---

¹ But very well indirectly! Consider:

template <typename T> using is_pointer = typename meta::is_pointer<T>::type;

Where meta::is_pointer<T> corresponds to the current std::is_pointer<T> type.

Answer 1

The most concrete answer to your question is: No one ever proposed doing it that way.

The C++ standards committee is a multi-national, multi-corporation collection of volunteers. You’re thinking of it as a design committee within a single organization. The C++ standards committee literally can not do anything without a proposal to put words into the draft standard.

I imagine that the reason there was no proposal is that type traits was an early proposal, with the boost implementation dating back to around 2000. And template aliases were late in getting implemented. Many of the committee members are reluctant to propose something that they have not implemented. And there was simply little opportunity to implement your proposal.

There was a lot of pressure to ship C++11. It really was intended to ship in 2009 and when that ship date slipped, it was very tough to do anything to the working paper besides fix the features already under consideration. At some point you’ve got to put great new ideas on the back burner, lest you will never ship.

Update

As of C++14, the TransformationTraits (those which result in a type) now have template alias spellings, for example:

template <bool b, class T = void>
  using enable_if_t = typename enable_if<b,T>::type;

And the C++1z working draft now has template variable spellings for the traits resulting in values:

template <class T>
  constexpr bool is_pointer_v = is_pointer<T>::value;

Also, even in C++11 one could do:

typename enable_if<is_pointer<T>{}, size_t>::type
address(T p);

I.e. you can use {} in place of ::value (assuming your compiler has constexpr support). In C++14 that becomes:

enable_if_t<is_pointer<T>{}, size_t>
address(T p);

And in C++1z:

enable_if_t<is_pointer_v<T>, size_t>
address(T p);

Note that the difference between C++1z and C++14 is so minimal that it doesn’t even save characters, just changes {} to _v and changes where you put these two characters.