Making Win32 APIs More Accessible to More Languages
One issue I&#x27;ve had with any kind of auto-generated bindings based on metadata is that you get low-level types such as &quot;Win32 BOOL&quot; and &quot;Win32 GUID&quot; 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:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;uuid" rel="nofollow">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;uuid</a><p>Similarly, Java has had a UUID type since v1.5: <a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;8&#x2F;docs&#x2F;api&#x2F;java&#x2F;util&#x2F;UUID.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;8&#x2F;docs&#x2F;api&#x2F;java&#x2F;util&#x2F;UUID.htm...</a><p>It&#x27;s not just concrete types, but core language concepts often &quot;don&#x27;t translate&quot;. 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&#x27;re <i>still</i> forced to wrap everything manually at least once to escape the &quot;unsafe&quot; sandpit.<p>A thought I had is that C is used for API definitions because &quot;it is lowest common denominator&quot;. But that&#x27;s the wrong thing to do, the metadata doesn&#x27;t have to &quot;sink to the lowest level&quot;! An <i>ideal</i> metadata definition would be something akin to Rust&#x27;s type system, or <i>even stronger than that!</i> &quot;Degrading&quot; 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&#x27;t synthesise this missing data!<p>Even the read-only guarantee is too weak. E.g.:<p><pre><code>    &#x2F;&#x2F; Rust could treat &#x27;buf&#x27; as read-only borrow.
    void SendData( [readonly] void* buf );

    &#x2F;&#x2F; 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...