为什么 std::is_constructible 在直接上下文中停止？

Question

源自this话题。也和这个topic有关。

我的问题是为什么std::is_constructible 会在当前上下文中停止？我认为std::is_constructible 的用户会期望它能够充分发挥作用并给出准确的答案。有了这个直接的上下文，你可能会让std::is_constructible 给你开绿灯，但在你实际这样做时却得到一个硬编译器错误。这不会违背std::is_constructible 的最初目标和目的吗？现在，它对我来说基本上看起来毫无用处。我猜std::looks_constructible_at_first_sight 将是当前语义的更好名称:(

Answer 1

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

template <typename... Ts, typename=decltype(base{std::declval<Ts>()...})>
aggregate_wrapper(Ts&&... xs)
    : base{std::forward<Ts>(xs)...} {/*…*/}

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

但是，重载解决方案并非旨在仅给出真正的否定/肯定：它旨在在给定适当参数的情况下找到最佳匹配，或者如果参数足够不合适，则不产生任何结果。 is_constructible 在某种意义上可能是肤浅的，但这就是特征的用途 - 检查签名，这是一个实体在重载解析和 SFINAE 领域的表示 - 不会阻止您的函数模板接受所有内容，而只是实际实例化一小部分论据的余量。
那是你的责任，如果你遇到了，你会从is_constructible和高效的编译中得到正确的结果。这绝对比is_constructible 的不间断操作和函数模板调用中大量隐藏规则的高编译时间要好。