Problem just here:
https://godbolt.org/z/35TW4vacY
    static_assert(std::is_copy_constructible_v<std::vector<std::unique_ptr<int>>>);

It is because before C++20 it is so difficult to restrict special member functions. I think we need add requirements in next standard as DR

вт, 13 июн. 2023 г. в 12:34, Federico Kircheis via Std-Proposals <std-proposals@lists.isocpp.org>:

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals