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

[Kari Oikarinen]

On 15.2.2020 16.23, Marc Mutz via Development wrote:
 > 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.

This serves as proof that our custom keywords cause issues occasionally,
but combined use of <osyncstream> and Qt won't be that common.

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

This plan requires everyone to drop the use of our custom keywords in
their code or to enable a new define to compile source code that worked
previously. As a backward-incompatible change I think it needs a strong
justification.

A couple of conflicts during 20 years that can be resolved with
equivalent effort (QT_NO_EMIT or QT_NO_KEYWORDS) but are only
encountered pretty rarely don't seem like a strong enough reasons to me.
Isn't the way to cause the least pain for our users to do nothing in
this case? The effort seems to be the same, it's just whether we impose
it on everyone or just the people encountering conflicts.

The rest of the thread has had a lot of discussion on what the possible
alternatives to annotating signal emissions could be or whether such a
thing is necessary at all.

But I think evaluating whether this warrants a move at all should be
considered more than it has. Alternatives may not be relevant if we're
not going to get rid of `emit` being defined by default.

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

We should co-operate better in the future. We definitely should *not*
add any new custom keywords. But is it worth tackling something very
common that causes problems relatively rarely?

-- 
Kari