On 14 Apr 2020, at 17:02, Matthew Woehlke <mwoehlke.fl...@gmail.com<mailto:mwoehlke.fl...@gmail.com>> wrote:
On 14/04/2020 05.28, Lars Knoll wrote: I believe there is mostly a consensus here to find a way to get rid of those macros. But many of our users do seem to like the ‘emit’ keyword as an annotation to a signal emission, and it is being used extensively in existing code bases. You know what would solve this? The ability to define a *reflection* operator (with proper name scoping) that could apply to statements and/or access protection specifiers. class MyObject { Qt::Q_OBJECT; public Qt::slots: ...slots here... }; MyObject::foo() { Qt::emit this->bar(); using namespace Qt; emit this->bar(); none->emit(...); // *not* the Qt::emit operator } If we played this right, maybe we could even reimplement MOC using reflection? (Stuff like Q_PROPERTY however might be hard, depending on if these operators are allowed to take a *space* delimited list of arguments rather than comma delimited.) Maybe, but we can’t solve it with current C++ standards. I think we should simply go and change the default for the QT_NO_KEYWORDS macro in Qt 6. Then, it’s Q_SIGNALS, Q_SLOTS and Q_EMIT by default, and you’ll need to use a #define to get them back: https://codereview.qt-project.org/c/qt/qtbase/+/297053 Cheers, Lars
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development