3 ms·
As far as I understand the proposal, it's "just" standardizing how some high level Rust types would be automatically translated into a "C ABI" compatible repres
by flohofwoe 4y ago
As far as I understand the proposal, it's "just" standardizing how some high level Rust types would be automatically translated into a "C ABI" compatible representation, sort of like a builtin bindings generator.
But I wonder why DLL linkage wouldn't already be possible without this proposal.
C++ doesn't have a standardized ABI either, but it's possible to load shared libraries with C++ interfaces just fine - as long as they've been created with the same compiler and compiler version. Since there's only a single Rust compiler vendor I'd imagine that dynamic linkage should already be much less trouble than in C++ land?
- lmm 4y agoRust moves much faster than C++, at least at the moment. So the practical benefit of sharing libraries created with the same compiler version would be much smaller.
- leni536 4y agoC++ absolutely has standardised ABIs, like the Itanium C++ ABI implemented by clang and gcc. The situation is not any better or worse than for C.
- pjmlp 4y agoAnd on Windows, COM and WinRT, although they are language agnostic.
- Rusky 4y agoDLL linkage with the same compiler has been possible since the beginning- for instance rustc itself is built this way. This is about going beyond that so people can interop with other languages, link with DLLs without rebuilding them every 6 weeks, etc