> I would also suggest you reconsider the functionality of importing C headers directly.
Trust me, as this is not as good of an idea as you think. You will just wrap it regardless unless it is absolutely trivial, which in those cases, you could have manually written the code to call the foreign code. And even if it was not as trivial, the types will be mostly wrong too, which means you'd need to correct them.
> Just recently I had a project that uses WebGPU
WebGPU is a mess regardless. Automatic bindings would still not work as you'd expect. For this specific API, we will add it to the `vendor` library collection along with all of the other graphics APIs. No one has gotten around to adding it yet, that is all.
To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against. It rare, if ever, that you need to regenerate the headers every single time you compile your Odin code, and that you don't even have wrap the code. Wrapping the code is effectively equivalent to just writing it yourself.
I am talking from experience from other languages. Pretty much every time those languages have the automagical C header importer, they either:
* The code had to be wrapped any way
* The types need corrected (thus wrapping)
* Rarely work correctly
* Missed code
* It didn't include everything you needed (e.g. preprocessor values as named constants, macros that were effectively normal wrappers, etc)
Another problem is that Odin does not support C's way of doing bit fields either, so some concepts will not map directly either. This means that Odin would have to completely embed the entire C type system as part of its language, rather than have those types be _compatible_ and _transformable_ with Odin types.