This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Suggestions for convenience aliases in <type_traits>


I find myself wanting these quite frequently:

template<bool _Val>
 using __boolean_constant = integral_constant<bool, _Val>;

template<typename _Cond, typename _Tp = void>
 using __enable_if_t_ = typename enable_if<_Cond::value, _Tp>::type;

template<typename _If, typename _Then, typename _Else>
 using __conditional_t_
   = typename conditional<_If::value, _Then, _Else>::type;

One of the reasons I've avoided adding the last two is that I'm not
sure how to name them appropriately.

In Boost.MPL the trait that takes a type parameter as its first
template parameter is named enable_if, and the version taking a
non-type bool parameter is named enable_if_c, but in the std::lib we
dropped the _c suffix.

The alias templates above are named to be consistent with the similar
C++14 aliases, but with an additional _ suffix, which is consistent
with the invaluable __and_, __or_ and __not_ aliases we already have
in <type_traits> (which also have type parameters not bools).

Is that reasonable?

Another naming scheme I've considered is using _T or _T_ as the
suffix.

Does anyone think these should/shouldn't be added?

Anyone have any arguments for or against a particular naming scheme?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]