C++ Reflection and Qt MOC

Summary

This is a WORK IN PROGRESS page to understand the implications of "Reflection for C++" for the future of Qt and moc. TL;DR Reflection in C++26 might be insufficient for replacing moc. We may require token injection, function definition, string-based lookup; at least the first is C++29 material, don't know about the others. Extra fancy features like outputting extra JSON files (or embedding JSON in plugins) may be out of scope for this work. Why? moc extracts interesting metadata from QObject subclasses / gadgets / namespaces. This metadata is then used at runtime to implement many different QMetaObject facilities. C++26 will (likely) ship with compile-time reflection. This means that the work that moc does today (as an external tool, with its custom lexer and parser etc.) could be done by the compiler itself. In the future, this may unlock lots of interesting possibilities (e.g. templated QObjects) and reduce technical debt (no need to maintain our own C++ parser for moc). However, we're not sure how to get there just yet. Some questions that this work aims to answer: Can we replace moc with a pure C++ solution? Is there something missing from standard C++ that we need for moc? How many source code (API) breaks are to be expected? If there's breakage, can porting tools automate the transition? Are there going to be issues with buildsystems? Reflection for Standard C++: references Papers that are interesting for Qt: moc extracts: the class name the parent class name (following QObject's inheritance chain) properties (Q_PROPERTY) invokables (methods marked with Q_INVOKABLE, Q_SIGNAL, Q_SLOT; may include constructors) for each invokable, also the parameter lists, i.e. types+names of the arguments; and whether they're defaulted (Qt considers these as separate overloads) the revision number (Q_REVISION) Q_CLASSINFO metadata Q_ENUM and Q_FLAGS Q_INTERFACES Class name Should there be no problems, `display_string_of` and friends give us this info. Parent class Again, no pro...