Hello Andrey,

"The default-generated functions have very simple and clear semantics."
"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."

Consider this case (note that this is true for most classes that refer to
resources):

Class OperatingSystemFile {
public:
// Various interesting stuff
private:
F mTheFile; // The type of F is something specific to the OS
};

What does "operator == ()" mean? There are (at least) three reasonable
definitions: 1) Do not allow it; 2) We are referring to the same file; 3)
Two different files have the same content. The default implementation is a
binary comparison of "mTheFile". That definition does not match any of the
above three possibilities. In fact, on Unix and Windows systems, it could
never be true because file handles are not duplicated.

What if "OperatingSystemFile" was just a class I had written for myself?
Yes, I was lazy. The point of "explicit" allows me to use this class (for
whatever purpose) and postpone the definition of "operator ==()" until I
need it. Without "explicit", I run the very real risk of using "operator
==()"!

You may not like the notion of "enabling" a lazy programmer. That is fair,
however, one of the primary purposes of type-safety is to detect human
error. I believe it is safe to say that it is better to provide a means to
make better programmers then to mandate that they be better from the start.

Also note that "explicit" is optional. Just the same as it's use for a
constructor and for "operator bool()". You don't like it or see the need
for it, don't use. It is not intended to be forced on you!

================================================

"People normally don't write a program that never terminates."

When talking about C++, we must consider more than just the "normal" uses.

================================================

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

Consider a POD. The presence or absence of a destructor will have no
bearing on correct program termination. However, the compile time error
would be beneficial. This is because it would make the programmer aware
that there may be a situation that they did not consider! Once again
providing some help to a less-than-perfect programmer.

=================================================

On every computer I have used (since 1972) some hardware is eventually
mapped to fixed memory locations. On Unix and Windows systems, this is in
the kernel. On todays "little" processors, (like the Arduino), this is in
user space because that is the only space. There is a technique to describe
this memory (using placement new) that allows one to describe the bits in a
nice way.

class HardwareResource {
public:
  uint8_t mControl1 : 3;
  uint8_t mData1 : 5;
};

HardwareResource & hr = * new (0x500) HardwareResource; // 0x500 is O/S
provided. We use a reference because there is nothing to delete!

"HardwareResource" is a perfect candidate for "explicit class". Its sole
purpose is to describe some memory that cannot be allocated or destroyed.
There are no default operations that make any sense.

=================================================

So, I beg you to consider that the world of C++ is extremely large,
encompassing many, many different uses and levels of programmers. This
simple addition has some utility. Not for you? That is fine!

I sincerely thank you for your time and feedback and look forward to further
debate!

Best regards,
Steve


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
Andrey Semashev via Std-Proposals
Sent: Tuesday, November 12, 2019 00:54
To: std-proposals_at_[hidden]
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
Subject: Re: [std-proposals] explicit class

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.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals