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

[Nathan Myers]

On 4/14/20 5:28 AM, Lars Knoll wrote:
> 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:
>>> 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?

Exactly.

The argument distinguishes components of official
ISO Standard 9945, already implemented and shipping
from (as noted) numerous organizations at the time
that ISO WG21 was convened. Such organizations each
ship an independently implemented C library, and
have no obligation or, often, inclination to pay the
slightest attention to the needs of a C++ Standard.

I.e., WG21 would have been shipping its Standard
Library Networking TS into a surrounding environment
where it would not work.

Qt, on the other hand, is fundamentally dependent on
the environment provided by ISO Standard 14882, and
stands to benefit from interoperating cleanly with
other users of 14882. Its users also benefit where
Qt interoperates cleanly with other libraries, not
excluding the Standard Library.

> 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.

I see that you are confused about the origins of Posix
and Unix networking practices, as well as WG21's. ISO
WG21 was convened in 1990. The ntohs etc. macros precede
1990. Qt does not.
> 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.

Many, many libraries are widely used. Many of those are
*much* more widely used than Qt. Yet, their maintainers know
better than to try to claim new core language keywords.

This point is worth dwelling on.

Among thousands, maybe millions of libraries, Qt, all alone
among them, claims authority on its own say-so to impose new
keywords on the core language it depends upon.

>> 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.

I am not personally responsible for the ISO  WG21 Library
Evolution Working Group's so *resoundingly* rejecting Marc's
proposal. I simply interpret the fact, for your benefit.

You are of course free to impute to the committee any
rudeness you like, or folly. Many people talk about WG21's
folly, but it is only our own folly that is under our
control.

>> 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 were 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.

Numerous other libraries could have got clever with macros.
But they didn't. That was not because they couldn't think of
it. They are, instead, aware of their place in the ecosystem.

Qt's failing was criticized immediately upon release.

Each day since, it has again not been fixed: day after day,
year upon year, failure piling on failure, thousands deep.
All fixable with one simple patch.

> 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.

Those users who want to continue using the macros will know
how to get them, and can then take personal responsibility
for their use. I feel confident they will not bother WG21
over any problems their choice causes them.

Nathan Myers