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_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
>