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

[Ville Voutilainen]

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.

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.

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

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