Hello Staffan,

I agree.

The root of this particular topic is about being able to "=delete" on a
destructor. As I have pointed out previously, classes abound that do not
require destructors and the compiler does not generate one.

If we are uncomfortable with the notion that a program never terminates,
that is fine. Let us eliminate that as an example. This leaves us the
question: Which is better, assuming that the compiler will generate a
destructor (even if does nothing) or being able to specify "=delete" on the
destructor. The latter gives us the opportunity to explicitly specify that
a class should not do anything in its destructor. In other words, that it
is a POD, and as such, one should seriously consider adding data members
that destruct!

Thanks,
Stevev

-----Original Message-----
From: Tjernstrom, Staffan <Staffan.Tjernstrom_at_[hidden]>
Sent: Tuesday, November 12, 2019 09:42
To: std-proposals_at_[hidden]
Cc: Steve Weinrich <weinrich.steve_at_[hidden]>
Subject: RE: [std-proposals] explicit class

My reading of [intro.progress] is that a conformant C++ program can always
be assumed to terminate, eventually.

>"People normally don't write a program that never terminates."
>
>When talking about C++, we must consider more than just the "normal" uses.

________________________________

IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the
sender immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of
this message or any attachment by an unintended recipient is strictly
prohibited. Neither this message nor any attachment is intended as or should
be construed as an offer, solicitation or recommendation to buy or sell any
security or other financial instrument. Neither the sender, his or her
employer nor any of their respective affiliates makes any warranties as to
the completeness or accuracy of any of the information contained herein or
that this message or any of its attachments is free of viruses.