为什么std :: is_constructible在立即上下文中停止？

Question

起源于这个话题。也与此话题有关。

我的问题是，为什么要std::is_constructible立即停止？我认为的用户std::is_constructible会希望它能够全面深入并给出确切的答案。有了这种即时的上下文信息，您可能会获得std::is_constructible开绿灯，而实际上却是在遇到硬编译器错误时。这不会破坏的最初目的和目的吗std::is_constructible。现在，对我来说，它基本上没有用。我想std::looks_constructible_at_first_sight对于当前的语义来说是一个更好的名字:(

Answer 1

如果你的构造函数的签名比应有的要宽松得多，那就是问题所在 - 而不是is_constructible其实现。在你原来的例子中，

\n\n

template <typename... Ts, typename=decltype(base{std::declval<Ts>()...})>\naggregate_wrapper(Ts&&... xs)\n    : base{std::forward<Ts>(xs)...} {/*\xe2\x80\xa6*/}\n

\n\n

完成工作。如果is_constructible“虚假地”亮了绿灯，那么您的构造函数模板可能会被虚假地选择而不是其他构造函数，因为重载解析发现它是最佳匹配。

\n\n

然而，重载解析的目的并不是只给出真正的否定/肯定：它的目的是在给定适当参数的情况下找到最佳匹配，或者如果参数足够不合适，则不会产生任何结果。is_constructible在某种意义上可能很肤浅，但这就是特征的用途 - 检查签名，这是重载解析和 SFINAE 领域中实体的表示 - 不会阻止你的函数模板接受所有内容，但实际上只是健全地实例化为了一小部分争论。
\n这是你的责任，如果你满足了它，你就会得到正确的结果is_constructible和高效的编译。这绝对比函数is_constructible模板调用中存在大量隐藏规则的可靠运行和高编译时间要好。

\n