[Development] Request for early MOC support for C++20 Modules

[Fabian Kosmale]

Hi Elias,

let's get your second question out of the way: Doesn't Q_PROPERTY(Qstring text MEMBER m_text) cover that already?

Now, for the actual question, moc supporting modules: That certainly wasn't a priority before CMake had official
support for modules, but granted, they do now support them, and the three big compilers have at least  some
 amount support for  them.  Still, I haven't seen much (Qt Company) customer demand there, though
as the ticket shows, there is quite a bit of community interest.

What would be needed to actually get module support into moc?
1. moc's parsing logic needs to learn about the relevant new keywords. moc needs to know at the very least the
   module (partition)'s name.
2. The generator needs to be adjusted to actually create valid code (basically what's described in the referenced bug).
    I expect some challenges there (e.g. what if your custom Q_OBJECT is only in an internal partition, but not in the
    primary module interface, can moc then find all necessary imports?), but  I guess the most trivial cases could
    be supported without too much work.

But I suspect your more interested in timelines, not the details of what the work entails. The ship has already sailed
for Qt 6.7. If we want  this feature in Qt 6.8, I see two ways forward:
- Someone contributes patches. As moc's maintainer, I can promise to review them timely
- There is enough interest (e.g. voiced here on the mailing list here, or by customers via support) that I can justify
   working on that feature myself.
If neither of the two happen, I expect this to slip to 6.9 (but then to be picked up for 6.9 due to the expected general
push for mandatory C++20 support in Qt)

Lastly, as mentioned on this year's Qt contributor summit, moc's current architecture as a glorified preprocessor
comes with its own challenges. I totally expect that to bite us when it comes to more interesting module use cases,
but it's not  a blocker for getting support for the "easy" parts in.

Fabian

________________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Elias Steurer via Development <development at qt-project.org>
Gesendet: Freitag, 15. Dezember 2023 14:36
An: development at qt-project.org
Betreff: [Development] Request for early MOC support for C++20 Modules

Hi Devs,

I'd like to ask about a possible roadmap update regarding C++20 modules support in moc. There was a discussion a while ago about C++20/23 support for Qt (https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and I would like to know if there has been any internal update. The corresponding bug report is https://bugreports.qt.io/browse/QTBUG-86697, but it seems that even more bump comments will not help. This is about ensuring moc can handle modules, not about converting Qt itself into a module. Getting moc ready for C++20 modules is something that could be done now, well in advance of Qt 6.9. For me, this is the only, and biggest, roadblock to adding modules support in my apps. Also, we shouldn't forget about tools like the QtRemoteObjects compiler that translates .rep files into .cpp/.h files (and possibly others?) that need updating too.

On a related note, when moving a class to modules, it would be handy to have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate code. My current classes are mostly 50% getter/setter boilerplate, and in my opinion, this is only manageable because we split our code into header and source files. This will be gone when using modules. So, I would like to see something like Q_PROP(QString text), that generates default get/set/notify code, and if needed, one could still use the old Q_PROPERTY(QString text READ text WRITE setText NOTIFY textChanged FINAL) if they need to add additional logic into the get/set functions.

Cheers,
Elias Steurer