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

[Nathan Myers]

On 4/13/20 3:41 PM, Ville Voutilainen wrote:
> On Mon, 13 Apr 2020 at 06:11, Nathan Myers <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.

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

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

Nathan Myers