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

[Elias Steurer]

Hi Fabian,

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

No, I still need all the get/set/notify functions to change/get the 
variables from the outside. There is currently no way to do that, or am 
I missing something? Something like this 
https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52 
but as a standardized Qt macro.

Thanks for the insight regarding moc timeline and challenges. Let's hope 
some customers voice their support 😊

Cheers,

Eli

On 12/15/2023 3:07 PM, Fabian Kosmale wrote:
> 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 ishttps://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231215/e3d4ce2e/attachment.htm>