为什么 CopyConstructible 类型也必须是 MoveConstructible？

Question

如cppreference 中所述，T 类型必须是CopyConstructible 的要求是它也是MoveConstructible。

STL CopyConstructible 概念的草案包含：

template <class T>
concept CopyConstructible =
   std::MoveConstructible<T> &&
   std::Constructible<T, T&> && std::ConvertibleTo<T&, T> &&
   std::Constructible<T, const T&> && std::ConvertibleTo<const T&, T> &&
   std::Constructible<T, const T> && std::ConvertibleTo<const T, T>;

它支持命名的需求语句。给定上面的定义，一个像这样的类型：

struct HaveCopy {
   HaveCopy(const HaveCopy&)  = default;
   HaveCopy(HaveCopy&&)       = delete;
   HaveCopy& operator= (const HaveCopy&)  = default;
   HaveCopy& operator= (HaveCopy&&)       = delete;
};

简单测试失败：

static_assert(std::CopyConstructible<HaveCopy>);

虽然它通过了旧的：

static_assert(std::is_copy_constructible<HaveCopy>::value);

那么，问题是为什么？标准委员会在这个问题上的意图是什么？ HaveCopy 不可移动构造，但在我看来几乎可以复制构造，std::is_copy_constructible<> 同意我的观点。

Copyable 概念也继承了相同的行为，即：

template <class T>
concept Copyable =
   std::CopyConstructible<T> &&
   std::Movable<T> &&
   std::Assignable<T&, const T&>;

所以测试：

static_assert(std::Copyable<HaveCopy>);

也会失败。这次失败加倍。 CopyConstrucible<> 和 Movable<> 都不同意 HaveCopy 是可复制的。

here 的讨论有点相似，但没有回答为什么。为什么我们需要这种行为？这种检查是否排除了有效的可复制构造类型，或者 HaveCopy 根本不能复制构造？如果是真的，最后一个对我来说真的很奇怪。

有什么想法吗？

Answer 1

是的，CopyConstructible 这个概念与类型特征 std::is_copy_constructible 完全不同。您专注于移动构造函数，但还有许多其他情况需要考虑。你认为这种类型应该是 CopyConstructible 吗？

struct A {
    A(A&) = delete;
    A(A const&);
};

这个怎么样？

struct B {
    explicit B(B const&);
};

关键是，您可以编写无数种构造函数组合。这并不意味着它们都有意义或值得支持。拥有一个带有复制构造函数但删除了移动构造函数的类型根本没有意义。

概念不仅仅是进行语法检查，它还涉及强制语义要求以推动有意义的类型 - 最终更容易编码。如果您只是检查is_copy_constructible，那么您所允许自己做的就是显式 从一个 const 左值构造您的类型。写T x = y;，即使y 是const T，也已经超出了这个范围！这可能是复制可构造的字面意思，但它比更广泛的“我可以从T 构造T”的意义要小得多——这更接近我们在考虑复制时的真正想法。这就是CopyConstructible 给我们的概念。

当您浏览该库时，与直接翻译其名称所暗示的相比，还有一些其他概念需要更多（句法和语义上）。 EqualityComparableWith<T,U> 不仅检查我是否可以写t == u，还检查u == t、t != u 和u != t。 StrictTotallyOrdered 不仅检查排序运算符，还检查==。拥有一个有凝聚力的整体很重要。