检查引用元组是否默认可构造时出错

Question

使用 g++-5 我得到以下输出

#include <type_traits>
#include <tuple>
int main()
{
  bool b;
  b = std::is_default_constructible<int>::value; //Compiles, returns true
  b = std::is_default_constructible<int&>::value; //Compiles, returns false
  b = std::is_default_constructible< std::tuple<int> >::value; //Compiles, returns true
  b = std::is_default_constructible< std::tuple<int&> >::value; //Does not compile
}

这是 is_default_constructible 实现中的错误吗？

错误消息是一个长堆栈列表，结尾为：

/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/../../../../include/c++/5.1.0/tuple:105:9: error: reference to type 'int' requires an initializer
  : _M_head_impl() { }

Answer 1

这不是 is_default_constructible 中的错误。该类型特征只需要检查默认构造的直接上下文，它不必深入评估任何成员初始值设定项。这个限制可能是为了可以通过使用 SFINAE 在没有专用编译器魔法的情况下实现它。（参见 [meta.unary.prop]，尤其是第 7 页）。

如果元素类型不能默认构造，则 tuple 和 pair 默认构造函数不需要在直接上下文中失败（SFINAE 友好）。 LWG 2367 已解决此问题，它为 tuple 默认构造函数引入了以下 SFINAE 要求：

Remarks: This constructor shall not participate in overload resolution unless is_default_constructible<Ti>::value is true for all i. [...]

有了这个额外的要求，元组的默认构造必须以 SFINAE 友好的方式失败，这样 is_default_constructible 现在可以用于 tuple 如果元素在直接上下文（引用类型就是这种情况）。

LWG 2367 目前处于就绪状态；提议的决议尚未（尚未）纳入 github 草案。

[-- 这部分还在考虑中

Yakk在评论中提出了一个重要的观点：为什么is_default_constructible必须深入实例化成员初始化器？

据我所知，这与 tuple 的默认构造函数的 条件 constexpr 主动性 有关。 is_default_constructible 导致默认构造函数的实例化。它只需要实例化声明，以确定是否可以在 即时上下文 中无故障地调用此构造函数。但是声明的实例化需要判断constexpr的主动性，这就导致了构造函数定义的实例化

已标记为 constexpr 的 class 模板的成员函数（或构造函数）仅是有条件的 constexpr：只有那些 class 的成员函数模板实例化将是 constexpr，其中正文不违反 constexpr 限制。这需要实例化构造函数的主体，以便构造函数检查 constexpr 函数内是否允许成员初始值设定项。考虑：

struct nonconstexpr { nonconstexpr() { std::cout << "runtime\n"; } };
struct isconstexpr { constexpr isconstexpr() {} };

template<typename T>
struct wrapper { T t; constexpr wrapper() : t() {} };

在实例化 wrapper 的默认 ctor 时，编译器必须实例化成员初始值设定项以确定此实例化是否应为 constexpr。

在 std::tuple 的情况下，这会在某处导致成员初始化器的实例化，该成员初始化器试图对引用元组叶（数据成员）进行值初始化。这是一个错误，它不会在默认构造函数的原始实例化的直接上下文中发生。因此，这是一个硬错误，而不是直接上下文中的替换失败。

--]

这部分对我来说并不完全清楚，因为 CWG 1358 基本上进行了所有实例化 constexpr，无论它们是否真正满足标准。事实上，gcc 6.0 不会编译以下示例，而 gcc 5.1 和 clang 3.7 会拒绝它：

#include <type_traits>

template<typename T>
struct foo
{
    T t;
    constexpr foo() {} // remove `constexpr` to make it compile everywhere
};

int main()
{
    static_assert(std::is_default_constructible<foo<int&>>{}, "!");
}

CWG 1358 还告诉我们为什么这两种方法之间的区别 - 条件 constexpr 和 constexpr 尽管违反 - 很重要：

Questions arose in the discussion of issue 1581 as to whether this approach — making the specialization of a constexpr function template or member function of a class template still constexpr but unable to be invoked in a constant context — is correct. The implication is that class types might be categorized as literal but not be able to be instantiated at compile time. This issue is therefore returned to "review" status to allow further consideration of this question.

对于 libc++，存在错误 #21157, which has been resolved on 2014-10-15 and appears in the clang3.6 branch. For libstdc++, there doesn't seem to be a bug report; the issue was fixed in a combined commit on 2015-06-30 which also implements N4387 - Improving Pair and Tuple (Revision 3) 目前似乎没有出现在任何 gcc5 分支中。

检查引用元组是否默认可构造时出错

Error when checking if a tuple of references is default constructible

c++

c++11

std

c++14

stdtuple