I think it can greatly ease the inter-op of Rust/C++, since we’ll be able to access the data directly…
I know it sounds a bit overkill, but i’d really like to see a library accomplish this with some minimal support from the language side… Then we’ll be able to provide more support for C++ headers.
Forgive my ignorance, but how #including a templated struct/class work in rust? What does that mean in terms of rust? In C++ templates aren’t checked until instantiation, would the rust compiler be doing this?
It shouldn't be quite that bad. This is only my personal understanding as well, but the situation at present should be that there is only one de facto C++ ABI per config.guess tuple, and that ABI will either be based on the "Itanium ABI" or it will be the Visual Studio ABI. Conveniently, LLVM already supports both.
Having said that, I suspect this is still a big can of worms, and it would be wise to scope it down a bit before even starting. What types of interop between a Rust caller and a C++ callee would actually be useful? How about the other way around?
It does. I confess I tend to think pragma pack is simultaneously too large and too feeble a hammer for nearly all situations, so I don't much care whether it works. :shrug:
(But wouldn't we just have to pass the pragma setting down to LLVM and let it do its thing?)
In the areas where C and C++ types intersect, #[repr(C)] should be fine for C++ interop. In the areas where C++ goes beyond C, especially templates and inheritance, I don’t think you can even express those types in Rust at all, let alone apply a #[repr(C++)] to it.
Or to reverse the question, what Rust types are you writing that can’t be #[repr(C)] but could hypothetically use a #[repr(C++)]?
