wt., 13 cze 2023 o 10:44 Federico Kircheis via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Tue, Jun 13, 2023 at 10:39:46AM +0200, Marcin Jaczewski wrote:
> >wt., 13 cze 2023 o 10:34 Federico Kircheis via Std-Proposals
> ><std-proposals_at_[hidden]> napisał(a):
> >>
> >>
> >> 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...)
> >>q
> >> 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
> >>
> >
> >You can't have cake and eat it too, "fix" would need to ban
> >use of forward declared types in vector:
> >```
> >struct Foo
> >{
> > std::vector<Foo> f;
> >};
> >```
> >Now this works fine, after it would not.
>
> Wouldn't it be possible to have vector play well with is_copy_assignable
> (ie delete copy-constructor if contained type is not copyable) if the
> type is not forward-declared?
>
> Granted, is_copy_assignable could still be wrong with forward-declared
> types, but it would at least work correctly for more use-cases.

This will fix nothing, as the vector needs to behave the same
whether the type is forward declared or not. You do not control it
as in some TU it will use forward declared type and in others it will not.
You will get multiple ODR problems where you check this condition.

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals