On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development <development@qt-project.org> wrote: > Qt relies on macros a lot, and while I have not followed the latest > Modules development, I'm sure macros pose a problem for a modularized > Qt, too.
Header units can still export macros. Macros don't go into header units or named modules from the client, but that doesn't save the situation - if you import osyncstream and #define emit (via whatever means), you still can't call osynctream::emit. So for modules, the clashes are not as likely, but they aren't completely unavoidable as long as emit is a macro. > <dreaming>Can access specifiers have attributes....? > public [[qt::slots]]: > </dreaming> That is pretty much exactly how the 'metaclass' (really just reflection+injection, with the reflection+injection metaprograms called from the class definition body, because that's where Q_OBJECT resides) approach envisions doing slots; there was an idea floated around that you could write public: ... current [[qt::slots]]: ... current: so that 'current' is just 'public', or actually whatever was the access at that point. Then 'slots/Q_SLOTS' can expand into 'current [[qt::slots]]:' and the meta-transformation can generate the code moc would generate today. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development