QtCS2024 C++26 Reflection: Difference between revisions
Ivan.solovev (talk | contribs) (→Notes) |
(added missing points) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 17: | Line 17: | ||
C++26 is not good enough, because we cannot detect signals and slots with reflections. | C++26 is not good enough, because we cannot detect signals and slots with reflections. | ||
No support at all currently for attribute reflection (needed for Q_INVOKABLE, method tags) | |||
Not enough support for function reflections (parameter list, default values, etc). | Not enough support for function reflections (parameter list, default values, etc). | ||
| Line 38: | Line 38: | ||
Giuseppe was nomintaed to do the research together with Thiago. | Giuseppe was nomintaed to do the research together with Thiago. | ||
We should talk directly to proposal authors, not to the commitee. Talk to Ville to get the contacts. Design freeze is Feb. 2025. | We should talk directly to proposal authors, not to the commitee. Talk to Ville to get the contacts. Design freeze is Feb. 2025, so we realistically cannot affect C++26, but we can request new features for next standard versions. | ||
[[Category:QtCS2024]] | [[Category:QtCS2024]] | ||
Latest revision as of 09:29, 8 September 2024
Session Summary
Session Owners
Thiago
Note taker: Ivan
Notes
What do we need to do to figure out if reflections in C++26 standard are good enough for us?
Where reflections are used: moc, QMetaType.
moc is the more interesting usecase.
C++26 is not good enough, because we cannot detect signals and slots with reflections.
No support at all currently for attribute reflection (needed for Q_INVOKABLE, method tags)
Not enough support for function reflections (parameter list, default values, etc).
QML actually needs parameter names, not only types.
Can we extract all the info that is generated by moc (6.9 version) from the reflections (constexpr, consteval)?
C++26 most probably wouldn't get reflection support for attributes - so, maybe not really useful for us?
What do we do with Q_PROPERTY?
We need build system support for reflections as well.
We do not need to be source-compatible with non-reflection code. We might request new syntax to support reflection.
Giuseppe was nomintaed to do the research together with Thiago.
We should talk directly to proposal authors, not to the commitee. Talk to Ville to get the contacts. Design freeze is Feb. 2025, so we realistically cannot affect C++26, but we can request new features for next standard versions.