The generator script, yes! I was taking inspiration from gen-operators.py plus a few others, including the introspection code in C++, Rust, etc. You're right about the similarity to the C++ binding approach. I did study the C++ implementation, and yes - Go's compile-time requirements make a non-typesafe call() method essentially impossible.

Technically, one could potentially achieve a dynamic implementation by passing arguments as raw byte buffers and doing runtime type reflection/marshalling or something similar - but the performance overhead would be huge. CGO is already quite slow compared to native Go code. The rule of thumb of calling C from Go is to minimize the number of calls between C and Go, hence pre-generating the possible paths. I believe there were Go projects that tried the dynamic approach, found it too slow, and went back to the hand-written arguments approach.

My first intention was actually to automate my hand-written bindings and to make sure the generated binding (e.g. tiffsave_buffer optional arguments looks like this) is no worse than my hand-written code. Since C is not my main language, writing the code by hand was not an easy job for me!

The automatic binary download idea is fascinating! Though Go needs to compile against the libvips headers, not just link to the shared libraries, which adds complexity.

Great point about reference leak testing - yes, a better test suite with leak checking would be at the top of my upcoming todo list. Reference management is tricky, and having automated validation would be invaluable.

I'd be honored to have a link in the libvips README! 🙏