dobkeratops
commented
2 years ago this is pretty interesting but I'd guess that Rust -> ObjC will be lower friction than Rust -> C++ -> ObjC. It's a shame they dont have some underlying C api (or do they?)
madsmtm
Apple recently announced official C++ bindings for metal. https://developer.apple.com/metal/cpp/
I was curious if it would be possible to use bindgen on it to autogenerate bindings to metal. If bindings are autogenerated, it might help avoid undefined behavior caused by incorrectly implemented bindings (there is no type checking for the objc calls from metal-rs into metal, but there could be type checking from metal-rs into code produced by bindgen)
The experience was mixed. The library includes a way to generate a single header file, and bindgen is able to parse it (use something like
bindgen metal.cpp -o src/bindings.rs -- -x c++ -std=c++17 -isysroot$(xcrun --sdk macosx --show-sdk-path). The produced rust bindings appear to be usable and some additional args passed to bindgen would permit allow-listing certain types/functions via matching their name prefixes.However, the downside is that all of the code in metal-cpp is meant to be inlined. So it would not be possible to link against functions in it from rust. Even if this were fixed by removing inline keywords (easy to do because it's a #define that can be modified), the name mangling is C++ based which I don't think is stable/portable in the same way that C functions would be.
So, for this to be useful, I think ideally the library should be wrapped in C functions. I imagine a determined person could automate generating them, and that it would be easier than automating generating C wrappers for objective-c. (cimgui might be a useful reference https://github.com/cimgui/cimgui).
(To be clear, I'm not strongly suggesting this for metal-rs. Just thought it was an interesting option and wanted to share in case others find it interesting.)