This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 118e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-11-05

1731. is_trivially_X and definitions of special member functions

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.