Why would trivial copy/move contructibility depend on trivial destructibility?

132 views Asked by At

A class with all special functions defaulted except a non-trivial destructor is not trivially move or copy constructible. See https://godbolt.org/z/o83rPz for an example:

#include <type_traits>

class Sample
{
public:
        Sample(Sample const&) = default;
        Sample(Sample&&) = default;
        Sample& operator=(Sample const&) = default;
        Sample& operator=(Sample&&) = default;
        ~Sample() {}
};

static_assert(std::is_copy_constructible<Sample>::value, "");
static_assert(std::is_move_constructible<Sample>::value, "");
static_assert(std::is_trivially_copy_constructible<Sample>::value, ""); // Fails with GCC and Clang
static_assert(std::is_trivially_move_constructible<Sample>::value, ""); // Fails with GCC and Clang
static_assert(std::is_copy_assignable<Sample>::value, "");
static_assert(std::is_move_assignable<Sample>::value, "");
static_assert(std::is_trivially_copy_assignable<Sample>::value, "");
static_assert(std::is_trivially_move_assignable<Sample>::value, "");

Both GCC and Clang fail the corresponding assertions, while ICC passes. Strange enough, assignments are not affected, despite I could understand that the assigned-to object needs to be destroyed. But it seems to be right the other way around. Why? And why does ICC disagree?

1

There are 1 answers

0
Fedor On

I see that comments already mention it. The answer is present in the notes section here https://en.cppreference.com/w/cpp/types/is_copy_constructible:

Same applies to is_trivially_copy_constructible, which, in these implementations, also requires that the destructor is trivial: GCC bug 51452 LWG issue 2116.