Automatically create bindings using C++26 reflection (example included)

[matthewkolbe]

Having dabbled in other languages that have reflection, the one thing I've gravely missed in C++ is the fact that you have to write and maintain so much boilerplate for external bindings and serialization. But now with P2996 landing in bleeding edge C++ compilers, we can start doing exactly that.

I put together a proof of concept that adds a single function to nanobind:

nb::reflect_<^^MyEnum, ^^MyClass, ^^my_namespace>(m);

This automatically binds constructors, data members, methods, static members, enums, and free functions — including overloads. Pass a namespace and it discovers everything inside it recursively. Private/protected members are skipped. No strings, no manual .def() chains.

The implementation is a single header: include/nanobind/nb_reflect.h on the reflect branch of my fork, with tests and docs following the existing nanobind conventions.

Since P2996 requires a bleeding-edge compiler (GCC trunk or Bloomberg's clang-p2996 fork), I also set up a test harness repo with Dockerfiles that build each compiler from source so anyone can try it without installing anything globally.

This is just a jumping-off point for ideas. There's plenty left to explore (operator mapping, inheritance, virtual functions). But I wanted to show that we can make useful things right now, and that the future of leveraging reflection in nanobind looks very bright.

@wjakob has made it clear that nanobind will stick to C++17, but offered the possibility of a nanobind26 or something of that nature in the future. I personally would be pretty compelled to move to 26 for a feature like this.

[matthewkolbe]

I did a nanobind26 version of this. The test harness repo mentioned above can now use that version or a fork, depending on the shell script arguments. I wouldn't be terribly excited to manage a nanobind26 project. Not because I wouldn't want to put in the work, but because I don't think I'd be terribly good at it.

[wjakob]

Hi @matthewkolbe. This is actually super cool. A few questions/comments:

• This is completely orthogonal to the rest of nanobind, right? (i.e. no core changes needed)
• It seems like a kind of all-or-nothing approach. Would it make sense to support something like nb::reflect<MyClass>(m).def(...) to add further members? What if there is a member I do not want to bind? (which happen to be public).
• What about performance? Is this much slower than writing the binding code by hand and then compiling that instead?

[matthewkolbe]

For now, this is completely orthogonal, and can be hoisted out as a wrapper of existing functionality. There may be reasons to change core in the future, but the advantages of being a wrapper could outweigh wanting to try that.

All-or-nothing? You are correct about that for my demo, but adding nb::reflect<MyClass>(m).blocklist(...) would probably be easy for non-edge cases. But maybe when you get into nesting and overloads and all that, it becomes less clean. From experience, when I used automatic bindings via reflection in other languages, I almost always just chose to expose all, but I can certainly see why other people would want to exclude binding some features.

Performance? I'll see if I can do some tests. From what I've read, the reflection features execute very quickly, but importing the <meta> library is in the hundreds of milliseconds. This is all subject to change as compilers develop and optimize the P2996 specs, so I wouldn't observe measured performance today, and assume it's indicative of what we'd expect a few years down the road.

Of note, I haven't been paying a ton of attention to the P2997 proposal. I have been putting off doing a deep dive into it until it was in a released version of GCC. I am sure there are some other very powerful features that I don't even know about yet that would dovetail very well with nanobind, but I just don't know what they are yet.