The 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.

Yes 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.

> Rust would have to learn how to use C++'s name mangling, data alignment, and calling conventions to be able to invoke C++ functions.

This is already supported (via Bindgen).

Thanks for pointing me to this. Wow. Looks like I can finish learning Rust.

I 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++.

You 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.

There 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).

I'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.

All FFI in Rust requires `unsafe` so it's impossible to do this "without doing anything".