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.

Regards,
Maciej

czw., 16 lip 2020 o 19:02 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> 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) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>