5 ms·
Rust needs easy interop with C++'s ABI. Easy as in I should be able to "import Boost" and have it all mapped to Rust structures without doing anything. A big r
by zelly 7y ago
Rust needs easy interop with C++'s ABI. Easy as in I should be able to "import Boost" and have it all mapped to Rust structures without doing anything.
A big reason C++ took off was backward compatibility with C. Network effects. Today C++ has the role that C had in the 80s.
No one uses any other compiler but LLVM for Rust anyway, so who cares about compatibility with MSVC and others. This will also force adoption of LLVM, which can be a good incentive for LLVM to support it.
- khuey 7y agoAll FFI in Rust requires `unsafe` so it's impossible to do this "without doing anything".
- deleted 7y ago[deleted]
- comex 7y agoI think this is both possible and desirable. Basically, create a bridge between rustc and Clang, kind of like Swift's C importer, but far more complex in order to be able to do things like instantiate C++ templates on demand (perhaps even with Rust types as arguments!). However, it would also be extremely hard; I don't think any programming language has ever created such a tight bridge to C++. The existing approaches I've seen are: - Swig, rust-bindgen, etc.: Pass through auto-generated C ABI wrappers; support for generics is limited and requires declaring up front what types you want to instantiate them with. - D: You can bind directly to C++ if you rewrite your C++ header in D, generics and all... including the implementations of all inline functions. Both very limited, especially in template-happy modern C++.
- Jaxan 7y agoThere was Objective-C++, which combined Objective-C and C++. You could literally write both languages mixed together. Honestly, it was a Frankenstein monster. The semantics were very vague (especially since C++ uses raii and obj-c uses reference counting in a garbage pool).
- pjmlp 7y agoYou forgot about COM/UWP, which has taken the role originally though for .NET on Longhorn. The whole point of UWP was to improve COM to make it even better for language interop, increasing the kind of language features that can get exposed as COM libraries. Also the number one reason that if Rust wants to succeed as system language on Windows it needs to have first class support for COM/UWP.
- zelly 7y agoI'm no compiler expert, but I don't see why it has to be so difficult. Just make Rust use the C++ ABI. C++ code is compiled in separate translation units as C++ by the C++ compiler. The linker statically links calls to C++ code from object files created by the C++ compiler. That's it. Rust doesn't need to know how to deal with templates because templates are all instantiated by the time this happens. This means you have to write a lot of your fancy C++ logic in separate C++ source files (not headers), but that's the whole point, to use already written code. The only thing Rust has to do is pass pointers to static code and follow the calling and name mangling convention. Zero calling overhead.
- pornel 7y agoThe thorny issue is C++ templates, which are instantiated in a complicated way that depends on C++ syntax. You can't "just" compile and link Boost in (as you'd do with a C library). You have to compile a fragment of C++ source code for every line of Rust code that uses a Boost template, and you have to translate Rust code used in template arguments to valid C++ code, so that template substitutions will be valid. This seems doable for simple cases, but libraries like Boost push templates to their limits, so they're not the easy cases.
- zelly 7y agoYes I realized porting a template library to Rust would basically require implementing a whole new compiler (easily more difficult to implement than all of Rust). Like you said, the only workable way is to link to C++ source code (fully translated units/obj files) compiled by clang. Rust would have to learn how to use C++'s name mangling, data alignment, and calling conventions to be able to invoke C++ functions. See my other post in this thread. Basically it would be a "extern C++". The FFI to C++ would hopefully have as low overhead as "extern C" while making it easier for C++ codebases to gradually adopt Rust.