This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Suggestions for convenience aliases in <type_traits>
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 10 Jun 2014 11:30:36 +0100
- Subject: Suggestions for convenience aliases in <type_traits>
- Authentication-results: sourceware.org; auth=none
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?