c++ - 为什么 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“虚假地”亮起绿灯，那么您的构造函数模板可能会被虚假地选择，而不是其他构造函数，因为重载解析发现它是最佳匹配。

但是，重载决策并非旨在只给出真正的否定/肯定:它旨在找到给定适当参数的最佳匹配，或者如果参数非常不合适则不产生任何结果。 is_constructible 在某种意义上可能是肤浅的，但这就是特征的用途 - 检查签名，这是一个实体在重载决议和 SFINAE 领域的表示 - 不阻止你的函数模板接受一切但实际上合理地实例化一小部分参数。
这是你的责任，如果你满足了，你将从 is_constructible 和高效编译中得到正确的结果。这绝对比 is_constructible 的可靠运行和在函数模板调用中具有大量隐藏规则的高编译时间要好。