C++26 reflections have been one of the most anticipated features in the language’s history. The ability to inspect and manipulate program structure at compile time, without resorting to macro soup or template gymnastics, has been a long-standing wish for developers working in domains where boilerplate is unavoidable.
Boris Staletić documented what happens when you actually try to build something real with reflections, specifically automating the generation of pybind11 bindings. The full retrospective on isocpp.org is candid in a way that conference talks rarely are: it shows where the feature shines, where it stumbles, and what the language still needs.
The pybind11 use case is a sensible one. Writing bindings between C++ and Python by hand is tedious and error-prone. You end up duplicating type information, function signatures, and documentation across multiple files. Reflections offer the possibility of deriving all of that from the original C++ source automatically, which is the kind of thing that sounds too good to be true until you sit down and try it for a month.
What Staletić found is roughly what you would expect from any early adoption story: the core mechanism works, but the surrounding language support still has gaps. Some things that should be straightforward require workarounds. Certain patterns that reflections were designed to enable turn out to need additional features, like generalized pack indexing or expansion statements, to reach their full potential.
This is a useful data point for the C++ committee. Language features do not get battle-tested in isolation; they get tested by people trying to build real things with them. The friction points Staletić encountered map directly to the kinds of ergonomic improvements that will shape the feature’s evolution past C++26.
From a systems programming perspective, the tension between power and complexity is worth paying attention to. Reflections operate at compile time, but compile-time computation carries its own cognitive overhead. Reading reflections-based code requires holding two models in your head simultaneously: what the code does at runtime, and what the compiler is doing during translation. That is a non-trivial mental load to sustain across a large codebase.
For projects that bridge multiple languages, the promise of automated binding generation is real. The alternative, hand-written FFI glue, is a maintenance burden that compounds as APIs evolve. Getting reflections to a point where they can reliably automate that work would be a genuine improvement for anyone building at language boundaries.
The retrospective framing of Staletić’s post, looking back on a sustained experiment rather than presenting a polished tutorial, makes it worth reading even if you are not working in C++ right now. It is the kind of honest engineering writing that helps calibrate expectations about where a technology stands versus where it is headed.
C++26 reflections are promising but not finished, and understanding that gap is the first step toward using them well.