This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115c. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-09-25
Consider an example like,
struct A { A() = default; A(A&) = default; A(const A&) = default; }; static_assert(!__is_trivially_copyable(A),""); struct B { A a; B() = default; B(const B&) = default; }; static_assert(__is_trivially_copyable(B),""); struct C { mutable A a; C() = default; C(const C&) = default; }; static_assert(!__is_trivially_copyable(C),"");
Presumably, all static_assert() conditions above are desired to evaluate true. Implementations diverge on this.
To decide whether a class is trivially copyable (Clause 11 [class] paragraph 6) , we need to see whether it has a non-trivial copy constructor. So eventually we hit 11.4.5.3 [class.copy.ctor] paragraph 12:
A copy/move constructor for class X is trivial if it is not user-provided, its declared parameter type is the same as if it had been implicitly declared, and if
class X has no virtual functions (11.7.3 [class.virtual]) and no virtual base classes (11.7.2 [class.mi]), and
the constructor selected to copy/move each direct base class subobject is trivial, and
for each non-static data member of X that is of class type (or array thereof), the constructor selected to copy/move that member is trivial;
otherwise the copy/move constructor is non-trivial.
which seem to imply that the copy constructor needs to have been implicitly defined before we consider this rule. But copy ctors are not odr-used in this example, so they're not implicitly-defined (paragraph 13).
The same considerations apply to copy/move assignment operators.
It might be sufficient to clarify this specification by replacing “selected to” with “that would be selected to.”
Rationale (September, 2013):
CWG felt that the existing wording was clear enough.