Re: Suggestions for convenience aliases in <type_traits>

[Daniel Krügler <daniel dot kruegler at gmail dot com>]

2014-06-10 12:30 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>:
> 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;

These make certainly sense, yes.

> 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.

IMO the comparison with the corresponding boost traits is not a good
one, because alias templates are not evaluated lazily, so
__enable_if_t_ or __conditional_t_ leads to the incorrect assumption
not to evaluate the provided predicate.

> 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?

Personally I consider these as bad examples for alias templates and
suggest to provide corresponding class templates instead (such __and,
__or, __not).

- Daniel