> A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly.
We do want to have an official bindings generator as part of the toolchain. There have been numerous third-party ones that people have created, but we need to have an official one now.
However, automatically importing C headers is not actually what virtually anyone wants in practice. Once you have imported the C header file, you pretty much want to:
* wrap the entire thing
* change the types to better reflect what things are (using Odin's richer type system)
* change names of things to better reflect usage and intent
* reorganize the declarations to better read things
* etc
There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers:
> There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automatically or find an existing one. So had to go with C++.
Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin.
Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests.
Bitfields - In my line of work this is a must-have.
> 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.
> 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.
Ok I understand now. I think even having such a tool i.e. to generate bindings from a C header file would be godsend.
> WebGPU is a mess regardless.
Interesting, it's not perfect but better than writing shaders in multiple languages and maintaining multiple render pipelines. Right?
We do want to have an official bindings generator as part of the toolchain. There have been numerous third-party ones that people have created, but we need to have an official one now.
However, automatically importing C headers is not actually what virtually anyone wants in practice. Once you have imported the C header file, you pretty much want to:
* wrap the entire thing
* change the types to better reflect what things are (using Odin's richer type system)
* change names of things to better reflect usage and intent
* reorganize the declarations to better read things
* etc
There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs.
And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers:
* https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx... (and the rest)
* https://pkg.odin-lang.org/vendor/sdl2/ and https://github.com/odin-lang/Odin/tree/master/vendor/sdl2
> Better tooling and standard library improvements.
Any concrete examples/ideas that you can give?
---
[1] https://odin-lang.org/docs/overview/#foreign-system