The binding between C++ and Python has always been written by hand. For each type you expose through pybind11, you register methods, fields, and constructors manually:
py::class_<Foo>(m, "Foo")
.def("bar", &Foo::bar)
.def_readwrite("x", &Foo::x);Scale this across a large API and you have a maintenance problem that compounds with every interface change. C++26 reflections offer a way out: inspect the type at compile time, enumerate its members, and emit the registration code automatically.
Boris Staletić spent a month testing that path. His retrospective on isocpp.org, published in November 2025, is worth reading because he stayed with the experiment long enough to encounter the hard cases.
What Works
The core loop is viable. Reflections can walk the members of a class, distinguish methods from data members, and drive pybind11 registration calls. For straightforward types, the result matches what you would write by hand. The machinery is expressive enough to handle the common case, and for a feature that is still in early adoption, that is meaningful.
Where It Gets Hard
Overloaded functions require explicit disambiguation. The reflection API exposes them, but producing the right .def() call for each overload needs careful handling. Non-trivial constructors add another layer. Some patterns that feel natural in ordinary template metaprogramming become awkward when expressed through the reflection API.
Statetić identifies features like generalized pack indexing and expansion statements as the pieces that would close the remaining gaps. C++26 reflection works as a foundation; it is not, on its own, the complete solution.
The Tooling Situation
C++26 is still catching up in terms of compiler support. Working against an emerging standard means debugging two things at once: your code and the implementation. That friction is inherent to early adoption rather than a criticism of the feature itself, but it shapes what conclusions are safe to draw.
Why This Matters
Hand-written FFI glue is a recurring cost for any team maintaining a C++ library with a Python interface. If reflections can automate that work reliably, the engineering payoff is real. The experiment shows the potential is there; the remaining gaps are in the language and tooling, and they are specific enough that you can see where things need to go next.
For anyone tracking the evolution of C++ metaprogramming, this retrospective from November 2025 gives you a useful baseline. Reflections are usable today for the straightforward cases, and the rough edges are concrete enough to inform what the language needs to close the distance.