Perhaps there is a way to improve the error message instead of tackling behaviour? Can the standardization help, e.g. with a standardized hint / attribute / ..., which could be used by the compiler for creating a better readable message?   -----Ursprüngliche Nachricht----- Von:Federico Kircheis via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 13.06.2023 10:34 Betreff:[std-proposals] copy constructor of std::vector An:std-proposals_at_[hidden]; CC:Federico Kircheis <federico_at_[hidden]>; Hello to everyone, please consider following snippet ---- #include <vector> #include <memory> struct s{     std::vector<std::unique_ptr<int>> d; }; static_assert(!std::is_copy_assignable<std::unique_ptr<int>>::value); static_assert(std::is_copy_assignable<std::vector<std::unique_ptr<int>>>::value); static_assert(std::is_copy_assignable<s>::value); void bar(){ s s1; // fails, as expected, but inconsistent with is_copy_assignable auto s2 = s1; } ---- Doesn't the second static_assert bother anyone? Vector is always is_copy_assignable, but in fact it is a compile-time error (auto s2 = s1) does not compile. Depending on the compiler, compiler errors are also verbose (https://godbolt.org/z/3E49c4oT7) and not necessarily easy to understand (immagine if s is part of a class hierarchy or a member of another class...) An improvement for the end-user is to delete the copy-constructor of s by hand, it does not change what programs are valid, but the error message is much more easy to understand. But it does not fix the underlying issue, and the fact that one cannot simply follow the "rule of 0" and let the compiler use the defaulted copy and move constructors without writing them down. Does anyone know if there is already a paper trying to fix this issue, or if there was one and was rejected? I assume the main difficulty is specifying something that also works with forward-declared types. Thanks Federico -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals