On 2019-11-12 03:26, Steve Weinrich wrote:
> Hello Andrey,
>
> The practical case is primarily for the developer of a class, not the user of it. Think about a smart-pointer class. During development, one is required to consider every possible aspect of the class. Using explicit, one could develop only the minimum aspects and add others as required and/or realized. I have certainly been surprised myself on many occasions by using operators that I had not considered.

The default-generated functions have very simple and clear semantics.
You may forget to redefine some of the operations if you require some
non-trivial logic instead of the default behavior, but you could as well
forget to add "explicit".

I'm not convinced that requiring the developer to implement every
operation of the class manually would be beneficial. In my practice,
when I write a class I know which operations should be non-trivial and
therefore be manually implemented, and which ones need to be deleted. It
often directly follows from the class' intended use. At the same time I
don't want to waste my time manually implementing operations that I know
are fine in default implementation. I purposely asked about the
destructor because this function is always required (yes, always) and
often is fine being the default. If anything, I would like more
functions to be defaulted, like comparison operators, for example.

> As to the destructor, my answer is yes. Consider a class that holds global state for a non-terminating process. We would certainly want the developer to consider what should happen if the object somehow gets destroyed! The explicit keyword would force such thinking.

People normally don't write a program that never terminates. You have to
have some condition upon which you terminate. At least, on user input or
a signal.

Global objects must be destroyed at program termination, so having their
destructor deleted would be a compile time error.