[pornel]

The Windows meta-API thing is done: https://lib.rs/windows

We'll probably continue using C headers as a poor ABI definition format, even without writing programs in C. Sort-of like JSON used outside of JavaScript, or M4 known as autoconf syntax, rather than a standalone language.

But C headers as an ABI definition format are overcomplicated and fragile (e.g. dependent on system headers, compiler-specific built-in defs, and arbitrary contraptions that make config.h), and not expressive enough at the same time (e.g. lacking thread-safety information, machine-readable memory management, explicit feature flags, versioning, etc.).

So I think there's a motivation to come up with a better ABI and a better ABI definition format. For example, Swift has a stable ABI that C can't use, so there's already a chunk of macOS and iOS that has moved past C.

[jstimpfle]

Not disagreeing about the issues of header files and the difficulty of consuming them from other languages (which was my point).

But regarding ABI definitions, I suspect that introducing "thread-safety information, machine-readable memory management, explicit feature flags" will make interopability at the binary level difficult or impossible, which is even worse.

[pornel]

Why do you think so? These things don't define binary layout, so they shouldn't interfere with it. In the worst case the extra information can be ignored entirely, and you'll have the status quo of poor thread safety, fragility of manual memory management, and crashes when the header version is different than binary .so version (the last point is super annoying. Even when the OS can version .so libs, C gives you absolutely no guarantee that the header include path and defines given to the compiler are compatible with lib include paths given to the linker).