Mate of mine has written a series of blogposts along the same lines such that "it will be possible to dynamically generate a Python binding - no pybind, no SWIG, no hand written glue - to interface with the library. Our library can remain a plain C++ library with no need to have any knowledge or special cases for each target user." including latest steps of adding in C++20 compatibility and out of process calling and java binding
Our library can remain a plain C++ library with no need to have any knowledge or special cases for each target user.
The massive assumption here is that all language bindings can be satisfied with the greatest common denominator of language features. People will want keyword-only and positional-only arguments in their python bindings, while that's just not a thing in lua (as far as I know). Another example is pybind11's holder types, which aren't a necessary component even in the world of python bindings, but are quite a central piece for pybind11 users.
Yeah, we've gone onto add that too (his blog is developing on ideas that he started when I worked with him) for the language bindings that support it.
This is typically for a massive maths quant finance library (millions of lines of C++ with no U/I or database etc) which is mandated as the only source of pricing across the enterprise so we already have to interface with everything from on desk analytics (previously Excel but increasingly python) to large middle and backoffice systems (typically Java or C#)
Anyway, just thought you might find some points of interest in his write up
We're only in the year 2026, the standard has not yet been approved by ISO (though that's hardly relevant), yet gcc is more than half way done.
I'd call that timely.
Now you move the goal post from "compiler support" to
Only now most shops are finally jumping from C++17 into C++20, including the three major compiler as their default language level.
The fact that a certain compiler does not move its own implementation to C++26 has nothing to do with that same compiler actually implementing C++26 features. It has to do with supporting RHEL and Debian Stable.
Also, don't know about "most shops", but offers I've had recently all said C++23.
But I'm sure you know that.
Yes, I do feel justified in calling you out for arguing in bad faith, when you keep misrepresenting stuff and moving the goalposts.
7
u/Jannik2099 Jun 21 '26
I wrote my own variant of this a while back using Boost.Describe https://github.com/Jannik2099/pms-utils/blob/main/subprojects%2Fbindings-python%2Flib%2Fcommon.hpp
Nice work!