[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

On 14 Apr 2020, at 10:17, Nathan Myers <ncm at cantrip.org<mailto:ncm at cantrip.org>> wrote:

On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers <ncm at cantrip.org<mailto:ncm at cantrip.org>> wrote:
The prevailing feeling in the room, when the vote was taken,
was that Qt people  MUST  BE  SMOKING  CRACK  if they think
the ISO 14882 C++ Standard should or would tiptoe around Qt's
aggressive abuse of lower-case macro names. That Qt has abused
them for a long time makes the abuse exactly that much *less*
excusable. To wit: you cannot claim you didn't know better.
While the argument was indeed made that the prolonged time
we have had lower-case macros in our public API makes
accommodating them less appealing for WG21, the
'prevailing feeling' is something where you speak on behalf
of a working group without the authority to do so,
and it's highly questionable whether that feeling
was as prevailing as you suggest.

Neither does Ville have authority to speak on behalf of
the Library Evolution Working Group.

But Ville, Marc, and I are all well-equipped to interpret
the (unusually large) number of "Strongly Against" votes
cast in this instance. Sugar-coating the outcome of that
vote benefits no one.

The WG was firm but polite, this once. Expect greater
firmness, and less politeness, next time. Take the hint.

It also doesn't require smoking crack to suggest that
WG21 considers code breakage due to new identifiers clashing with existing macros; they've done so before,
when the Networking TS and its functions with names like
ntohs and htons clashed with macros.

Ville is certainly aware that the instance he cites involved
macros that (a) commonly appear in vendor System C Library
headers, from numerous sources, and (b) *long* precede the
existence of ISO WG21. Neither of the above applies to Qt
header abuses, which (as Marc has noted) are trivially
remedied by fixing a single header file in a single library
distribution, and could have been as easily fixed on any
day of the past 20+ years.

What kind of argument is that? htons as a macro was worth considering, but the ones in Qt are not?

Fixing the htons macro also "only requires changing one place" in the System C library. You are forgetting, that both changes break a huge amount of user code out there. And Qt’s macros have been around for about just as long (25 years), so they also *long* precede the existence of ISO WG21.

Yes, there is a difference because Qt is not a system library, but it is nevertheless very widely used, so bringing the compatibility problem up as something to consider for the WG was certainly the right thing to do.

Asking the ISO WG21 C++ Standard committee to compensate
for one library's extended process failure is, at best,
rude and foolish.

I do agree that we should change this and get rid of the lower case macros. But blaming Qt here for keeping compatibility for our users while saying this is ok for system C libraries is just as rude.

It would not be at all surprising if uses of all the other
abused names--signals, slots, etc--show up in key components
of C++23. Asking the committee to change them could not
reasonably be expected to produce a peaceful outcome.
The outcome of this last asking was plenty peaceful
It is generally a mistake to confuse a polite but firm
rejection with an invitation to dance.

Marc's proposal is far too modest. Just change the default,
in a single step: eliminate the abusive macros, as any
responsible organization would have done *decades* ago.
(An accompanying apology for past abuse would not be out of
place.) Anybody who wants to keep using the abusive macros
already knows how. They will also know that they are
deliberately choosing to do The Wrong Thing.
Why? The users of emit don't care it's a macro, and if they
never use osyncstream, they don't run into this problem. Forcibly breaking their code without any sort of soft migration path  doesn't seem like a user-friendly way to
approach it.

Ville is certainly aware of why common lower-case words as
macros are ill-advised in public library headers.

He is also aware that the ISO Standard C++ Library is not
the only place where lower-case words are commonly used as
properly-scoped identifiers. The world offers thousands of
useful libraries, each equally or more subject to disruption
by a single needlessly ill-disciplined library header.

It is never the wrong time to step up and do the responsible
thing. How often do we find that ten thousand bad choices,
across decades, can be remedied by one good choice?

This was one choice that Qt did 25 years ago, not ten thousand. And signals/slots was a great concept and at that time (and it did get picked up by many other frameworks). The lower case macros where also seen as the correct choice (they weren’t conflicting and it was common practice in many frameworks). Yes, we should maybe have used something else, but in hindsight those things are always easy to see and even easier to judge.

I believe there is mostly a consensus here to find a way to get rid of those macros. But many of our users do seem to like the ‘emit’ keyword as an annotation to a signal emission, and it is being used extensively in existing code bases.

And except for the case of those three legacy macros (signals/slots/emit), I do believe Qt has been extremely careful to keep its headers clean.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200414/9dd1eb16/attachment-0001.html>