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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
