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

[Marc Mutz]

Hi,

C++20 will contain new classes with emit() member functions 
(wg21.link/P0053). While that will only pose problems for users that 
include the new <osyncstream> header after (almost) any Qt header, this 
should serve as a second shot across the bows (after namespace 
boost::signals) that we should change something.

To that effect, I'd like to propose that we switch the default for 
QT_NO_KEYWORDS around. I'd so this in three phases:

1. phase
  a. Add CONFIG += keywords (or the CMake equivalent) to act as an 
antagonist for no_keywords.
  b. Change the documentation, examples and Qt implementation to use the 
Q_<UPPER> macros

In this case, they just cancel each other out. This is just so you can 
already express the intent to continue to use lowercase keywords by 
saying CONFIG += keywords. It also makes sure that next generation of Qt 
programmers grows up with the Q_ macros, so they don't squint their eyes 
when they see

    Q_EMIT valueChanged(m_value);

2. phase
  a. Make no_keywords the default
  b. Change the documentation accordingly
  c. the QT_NO_KEYWORDS macro is left untouched

In this phase, projects that use qmake (or by some other means inherit 
Qt's default)

3. phase
  a. Replace QT_NO_KEYWORDS with a new macro QT_USE_KEYWORDS (or 
somesuch).
  b. Change the documentation accordingly

In this phase, even projects using not using Qt's defaults would switch 
defaults.

We can then stop there, or we use the years to come to decide how we 
want to transition off the macro stuff and consult with ISO C++ so they 
can work with us to give us the functionality to do so (meta-classes, 
qt::emit with overloaded whitespace operator, whatever).

I think it's clear that, as it is now, where for two years such a 
problem exists in the IS and doesn't get detected by "the Qt project", 
for a certain definition thereof, and only comes up by chance encounter 
at the last day of the last meeting before C++20 is "done", it cannot 
continue. Or, if it continues, Qt will be bitten more and more by stuff 
ISO C++ does. If ISO C++'s estimate for C++ programmers and TQC's claim 
for Qt developers are both correct, we're looking at a size of the 
intersection of the two groups of over 20% of all C++ programmers. I 
happen to be firmly rooted in both, and I'd be sad to see the two 
separate ways even more than they have done in the past.

Thanks,
Marc