Making Win32 APIs More Accessible to More Languages
One issue I've had with any kind of auto-generated bindings based on metadata is that you get low-level types such as "Win32 BOOL" and "Win32 GUID" polluting the output. Mainstream languages already either have native bool and guid types, or have defacto standard libraries.<p>E.g.: Rust has the UUID crate: <a href="https://crates.io/crates/uuid" rel="nofollow">https://crates.io/crates/uuid</a><p>Similarly, Java has had a UUID type since v1.5: <a href="https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm...</a><p>It's not just concrete types, but core language concepts often "don't translate". E.g.: Win32 is essentially a C-like set of bindings. In many languages such as C++, D, Zig, etc... this is not an issue. However the type system of C is much less strict that Rust, so the metadata has no concept of ownership and lifetimes. This means that if you want to consume Win32 APIs from Rust, you're <i>still</i> forced to wrap everything manually at least once to escape the "unsafe" sandpit.<p>A thought I had is that C is used for API definitions because "it is lowest common denominator". But that's the wrong thing to do, the metadata doesn't have to "sink to the lowest level"! An <i>ideal</i> metadata definition would be something akin to Rust's type system, or <i>even stronger than that!</i> "Degrading" a binding from a strong type system to a weak one is trivial and can be performed completely automatically. The converse is difficult and error-prone even for humans, and impossible for code generators. You can't synthesise this missing data!<p>Even the read-only guarantee is too weak. E.g.:<p><pre><code>    // Rust could treat 'buf' as read-only borrow.
    void SendData( [readonly] void* buf );

    // But here the borrow outlives the function call lifetime!
    void SendDataAsync( [readonly]void* buf );
</code></pre>
The two methods have identical metadata signatures, but the information required by a Rust programmer or a Rust code generator is missing...<p>There are many such abstract API concepts missing from C, such as thread safety, process integrity safety, non-returning calls, blocking vs async, etc...