As far as I understand the latest C++ draft, constexpr destructor doesn't make the type trivial. It is just that constexpr destructor is allowed to be called in constexpr context (while in previous C++ standards only types with trivial destructors were allowed in constexpr context).

So I guess this would fail to compile, because such a global would still require a runtime registration of the destructor during initialization.


czw., 16 lip 2020 o 19:02 Thiago Macieira via Std-Proposals <> napisał(a):
On Thursday, 16 July 2020 01:56:02 PDT Maciej Cencora via Std-Proposals wrote:
> Since implementing this is trivial, is there a chance to fix this as a
> defect report?

Pretty sure the answer to this question is "no", even if this is an
unintentional oversight and the change has no impact on existing applications.

Question on constexpr destructors. What happens in this case:

struct S
    bool b;
    constexpr S() : b(false) {}
    constexpr ~S() { if (b) abort(); }

constinit S s {};
int main()
    s.b = true;

The constructor for S is constexpr, so that constinit does not need load-time
dynamic initialisation for s. Without the constexpr in the destructor,
constinit would generate static initialisation of s and do a dynamic
registration of its destructor at runtime.

In the presence of that constexpr destructor, S becomes a trivial type. So is
constinit still required to register the dynamic destruction? And if not, why
it it acceptable that abort() isn't called?

Thiago Macieira - thiago (AT) - thiago (AT)
   Software Architect - Intel System Software Products

Std-Proposals mailing list