Reflection for C++26

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it.<p>Looking at the examples (<a href="https:&#x2F;&#x2F;isocpp.org&#x2F;files&#x2F;papers&#x2F;P2996R4.html#examples" rel="nofollow">https:&#x2F;&#x2F;isocpp.org&#x2F;files&#x2F;papers&#x2F;P2996R4.html#examples</a>) what really stands out is the direct integration of type-syntax into the language. It fits in with a certain token-substitution way that connects back to templates. It also replaces some of the uglier operators (typeof?).<p>I hope it goes int! During the language&#x27;s stagnation I left for a while, perhaps it&#x27;ll be competitive again soon.

While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things:<p>1. how immense the language has become, and how hard it got to learn and implement<p>2. how &quot;modernising&quot; C++ gives developers less incentives to convince management to switch to safer languages<p>While I like C++ and how crazy powerful it is, I also must admit decades of using it that teaching it to new developers has become immensely hard in the last few years, and the &quot;easier&quot; inevitably ends up being the unsafe one (what else can you do when the language itself tells you to refrain from using `new`?).

Do I understand correctly that this proposal does not include annotations (i.e. attributes).<p>More specifically, with this I can iterate over struct members and get their names and types, but I cannot attach additional information to these members, like whether they should be serialized or under which name.<p>The referenced proposal P1887R1 covers this, but that&#x27;s not included here, right?<p>P1887R1: <a href="https:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg21&#x2F;docs&#x2F;papers&#x2F;2020&#x2F;p1887r1.pdf" rel="nofollow">https:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg21&#x2F;docs&#x2F;papers&#x2F;2020&#x2F;p18...</a>

Can I ask a naive question that consists of two parts and please don&#x27;t flame me? lol<p><pre><code> * What type of problems static reflection could solve, in general? * Are there specific cases and &#x2F; or situations where static reflection could resolve such case, even simplify an unnecessary complexity?</code></pre>

I have been waiting for static reflection for the last 20 years. The current proposal seems quite nice, but the real question is whether any non trivial usage will kill compilation performance.

Finally. I think there have been proposals since C++17 at least, and all I really wanted is for them to solve the common problem of basic static reflection for enums (without hacks like magic_enum uses).

This looks surprisingly fine! The opaque, extensible types remind me of Win32 with its extensibility through ever new message types. The syntax looks better than expected, too - well, it&#x27;s better than templates...

FYI: this is the latest draft of the proposal and it has not been voted into C++26 yet, but it is getting close.

Note that there are links pointing to examples on Compiler Explorer, using the EDG and clang preview implementations.

With every new C++ feature, I can&#x27;t help to think &quot;Oh yea, cause C++ isn&#x27;t complicated enough&quot;

Highly interesting, I&#x27;m looking forward to this.<p>But the `member_number` functions in § 3.2 look disturbing to me. It&#x27;s not discernible how invalid arguments are handled. Normally I&#x27;d look at generated assembly to answer a question like that, but this probably doesn&#x27;t make sense with compile-time-fu (`constexpr`)…

Has finally the committee come to <i>reflection</i> after decades of standard revisions and footguns? &#x2F;j

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

I haven&#x27;t touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn&#x27;t Qt&#x27;s moc implement some of this stuff because it wasn&#x27;t available in C++? Could this replace moc?

I&#x27;m not convinced that wasting a simple clean syntax (prefix unary ^) is warranted for something that should be rare outside of a few libraries.

I&#x27;m surprised at the positive response in this thread. I find the syntax of this beyond atrocious! My goodness C++ really does not know how to do anything simply does it?

Oi vey. Poor C++. Look how they massacred my boy.

Ctrl-F &quot;networking&quot;, cry, close page...<p>See also: <a href="https:&#x2F;&#x2F;github.com&#x2F;cplusplus&#x2F;networking-ts">https:&#x2F;&#x2F;github.com&#x2F;cplusplus&#x2F;networking-ts</a>

How about: Deprecation for C++26?