Abstract:

This presentation by Inbal Levi, Library Evolution Work Group (LEWG) Chair, provides a technical deep dive into the static reflection feature slated for the C++26 standard (P2996). The session outlines the historical evolution from template-heavy libraries like mirror and Boost.Hana to the current "monotype" language-supported design. Central to this proposal is the std::meta::info type, which represents program elements by value within the std::meta namespace.

The talk details the primary syntax for reflection: the "unibrow" lift operator (^^) and the splicer operator ([: :]). It addresses critical design decisions, such as the stateful nature of reflection (where the result of a reflection query can change as a type is completed within a translation unit) and the enforcement of consistent parameter naming between function declarations and definitions. Levi concludes by analyzing the impact on library development, the role of reflection in the age of AI-assisted coding, and the introduction of constexpr exceptions for compile-time error handling.

C++26 Static Reflection: Syntax, Design, and Implementation

• 0:00 – Introduction and Context: Overview of the C++ Foundation and the specific working groups (SG7, LEWG, CWG) responsible for incubating the reflection proposal, one of the largest in C++ history.
• 5:36 – Defining Static Reflection: Reflection is the ability of software to expose its own structure to the compiler at compile time. C++26 focuses strictly on static (compile-time) reflection rather than runtime metadata.
• 7:46 – Historical Evolution: Traces the path from 2006's template-based mirror library to modern syntax. The committee transitioned away from template metaprogramming (TMP) for reflection because TMP imposes excessive compile-time overhead and complexity.
• 12:00 – The Monotype Design (std::meta::info): Unlike traditional OOP hierarchies, C++26 uses a single type, std::meta::info, to represent all program elements (types, namespaces, functions). This minimizes compiler burden and allows for heterogeneous algorithms that treat all reflected entities as uniform objects.
• 18:26 – Lift Operator (^^): The ^^ operator (the "unibrow") lifts a program element into the reflection realm, returning a std::meta::info object.
• 22:25 – Splicers ([: :]): Splicing is the inverse of lifting; it extracts a C++ expression or type back from a std::meta::info object, allowing reflected entities to be re-injected into the source code.
• 28:46 – Representation via AST Nodes: std::meta::info functions similarly to an Abstract Syntax Tree (AST) node reference, allowing queries on type aliases, functions, enumerators, and namespaces.
• 33:53 – Stateful Reflection Behavior: Reflection in C++26 is stateful. A std::meta::info object reflecting an incomplete type will update its "completeness" status as the type is defined later in the translation unit. This decision avoids the memory footprint required for "snapshotting" program states.
• 43:00 – Advanced Meta-functions:
  • substitute: The reflection equivalent of template instantiation, allowing for delayed instantiation of types and functions.
  • extract: A utility similar to any_cast for retrieving constant values from meta-objects.
• 49:22 – Function Parameter Naming Challenges: Because C++ does not have canonical names for function parameters (names can differ between declaration and definition), the committee voted to enforce consistent naming when using reflection to query parameter names. This may break existing codebases that utilize mismatched names.
• 57:18 – Reflection vs. AI and Rust:
  • AI: While AI can generate code, reflection provides deterministic and consistent results during every compilation.
  • Rust: C++'s reflection is compared to Rust's procedural macros and the syn library; C++'s approach is argued to be a more intuitive user interface for observation.
• 59:26 – Error Handling with Constexpr Exceptions: C++26 introduces the ability to throw and catch exceptions during compile-time evaluation. This allows reflection libraries to provide descriptive error messages that terminate compilation if uncaught.
• 1:00:52 – Future Impact: Reflection will allow developers to write complex "language-level" features (like loggers, serializers, and parsers) as standard libraries rather than needing to modify the compiler itself.