Boris Staletić spent a month in late 2025 doing something most C++ developers have only theorized about: writing production-oriented code against C++26’s static reflection proposal. His goal was to automate the generation of pybind11 bindings, eliminating the boilerplate that anyone who has wrapped a C++ library for Python knows well. The writeup on isocpp.org is one of the more honest accounts of what it feels like to push a new language feature against a real use case.
The Problem Worth Solving
pybind11 binding code is mechanical. For each class you expose, you write something like:
py::class_<MyType>(m, "MyType")
.def("method_one", &MyType::method_one)
.def("method_two", &MyType::method_two)
.def_readwrite("field", &MyType::field);Multiply this across a large codebase and you have a maintenance burden that grows with every API change. Reflection promises to collapse that work: inspect the type at compile time, enumerate its members, and emit the registration calls automatically.
Where It Works and Where It Frays
What Staletić found is that the promise holds, up to a point. The reflection machinery is expressive enough to walk class members, distinguish methods from fields, and emit registration calls. For straightforward types, it works well. The generated bindings match what you would write by hand.
The harder problems emerge with edge cases. Overloaded functions require disambiguation. Types with non-trivial constructors need special handling. Some patterns that feel natural in ordinary C++ template metaprogramming become awkward when expressed through the reflection API. Staletić is candid about these rough edges, and the post is worth reading specifically because he does not paper over them.
There is also the tooling situation. C++26 is not widely supported yet; the experiment required working with compiler implementations that are still catching up to the standard. That friction is expected at this stage of a language revision, but it shapes what conclusions are safe to draw.
What This Means for the Language
The broader lesson from the experiment is that C++26 reflection has practical utility outside of proposals and papers. The pybind11 use case is a good stress test because it combines metaprogramming, real library integration, and practical constraints. Getting it to work, even partially, demonstrates that the feature has enough surface area to matter.
The missing pieces Staletić identifies, better support for overload sets and richer introspection of function signatures, are the kind of feedback that shapes where the standard goes next. C++26 reflection, in its current form, works as a foundation; future language features and library tooling will build from what is there now.
For anyone working at the intersection of C++ and Python, this retrospective from November 2025 is worth the time. It is one of the clearer windows into what C++26 reflection looks like before the tutorials catch up and make everything seem obvious in hindsight.