C++17 中已弃用的 std::is_literal_type答案

【问题标题】：Deprecated std::is_literal_type in C++17C++17 中已弃用的 std::is_literal_type
【发布时间】：2017-03-14 02:31:09
【问题描述】：

根据 cppreference，特征 std::is_literal_type 在 C++17 中已弃用。问题是为什么和首选的替代品是什么，以便将来检查一个类型是否为literal type。

【问题讨论】：

【解决方案1】：

As stated in P0174:

is_literal 类型特征对泛型代码的价值可以忽略不计，因为真正需要的是知道特定构造会产生常量初始化的能力。具有至少一个 constexpr 构造函数的 文字类型 的核心术语太弱而无法有意义地使用。

基本上，它的意思是没有代码可以用is_literal_type_v 保护，并且足以确保您的代码实际上是 constexpr。这还不够好：

template<typename T>
std::enable_if_t<std::is_literal_type_v<T>, void> SomeFunc()
{
  constexpr T t{};
}

无法保证这是合法的。即使您使用is_default_constructible<T> 保护它，也不意味着它是 constexpr 默认可构造的。

您需要的是 is_constexpr_constructible 特征。目前还不存在。

但是，（已经实现的）特征没有害处，并且允许编译时自省给定模板参数可能满足的核心语言类型类别。在核心工作组放弃字面量类型的概念之前，应该保留相应的库特征。

移除（弃用后）的下一步是写一篇论文，提议从核心语言中移除该术语，同时弃用/移除类型特征。

因此计划是最终摆脱“文字类型”的整个定义，代之以更细粒度的东西。

【讨论】：

有趣的是，我认为std::is_literal_type 提供了一种安全检查，是否可以在 constexpr 表达式中使用类型。不过，这是一个很好的答案。
但是你能用它来检查函数参数吗，例如here 还是在某些情况下它也会中断？
@berkus：目的是什么？应用于模板的constexpr总是是有条件的。如果你用一个使函数违反constexpr规则的类型来实例化它，那么它就不会是constexpr。那么“检查”的意义何在？如果T 没有constexpr operator+（检查没有测试），那么函数也不会是constexpr。那么有什么意义呢？
@NicolBolas 不确定了，这是关于 C++ 的一些讨论，我已经忘记了。我想这是为了在违反 constexprness 时提供更明智的错误消息，但当前的 gcc/clang 似乎提供了相当精通的消息。很抱歉打扰您。
@NoSenseEtAl：实际上，我在 requires 表达式中的 constexpr 声明是错误的。它们只能有表达式，不能有这样的声明。