Not a working group, but a library does exist: https://cxx.rs/

The difference is that cxx is doing codegen to create a C ABI compatible bridge. So the same thing most people already do when they want to interact w/ C++ over FFI.

I believe that TFA is actually saying that the Swift compiler speaks C++ directly without doing any codegen and just handles everything at the compilation level. Same end result but a lot of subtle differences. Not having to do codegen is a big win, especially in Rust where compile times aren't terrific and binary sizes can already bloat up due to the statically linked nature.

Yes, cxx.rs is really good for what it is! There's also autocxx that aims at generating cxx bridges directly. What Rust lacks is, to my knowledge, a C++ interoperability working group. cxx.rs (which is useable but by no means finished) could be a topic of such a working group. Direct compiler support of C++ could be another.

A better C++ rust interop story is a critical piece for Rust's success IMO

I hope one does not need to write the signatures manually and tweak the cxx generator, for detecting flags, types and the like just to get it properly working. If that's the case, then that would be tons of maintenance and more trouble than its worth for a more complex C++ codebase.

Best to make that a first party feature built into the language compiler and have it do the majority of the work automatically rather than manually define the C++ types, functions, etc using a third party library.

I've asked around a bit, and so far I've found no language or tool that can directly access C++ libraries without manually writing bindings. I hope that can change sometime in the near future.

I know of two languages:

1. D (https://dlang.org/spec/cpp_interface.html)

2. Nim. Though this is a bit cheap because Nim is a frontend to C(++), so you're really writing C++ that calls other C++ when it boils down to it. See https://nim-lang.org/docs/manual.html#implementation-specifi...

There is one -> Objective-C++ - interop is very seamless (just change file extension from .m to .mm). I do hope as well that will change and we will see some other languages speaking to c++ so easily.

Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C++. Let C++ die! ;-) (only half joking)

So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust?

If C++ dies Rust will have a hard time replacing its GCV/LLVM backends.

Cranelift as it stands today won't do it.

>> Let C++ die!

> So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust?

Death of a language isn't a clear cut thing that really happens, so everyone has their own definition. Some consider a language dead when they fall from former glory, so for a popular language they don't need to disappear, they can even have multiple thriving niches and still be considered "dead" because they are a portion of the usage they used to have (see Python 2, still widely in use, but I can make argument to call it "dead"). Others consider a language dead when direct competitors are used instead of them for new projects (see Perl). Yet others consider a language dead when there's an active and thriving effort to migrate existing applications to other languages. All of these are varying interpretations of "dead language". I would call Delphi, Perl, Python 2 "dead", yet there are plenty of projects in use out there written in those languages, and in some cases even thriving communities. But even if their absolute numbers don't decrease, the rest of the world might continue to out grow them into "irrelevance" (whatever one might want to consider that to be).

All that to say: C++ doesn't need to disappear to "die", it doesn't need to die for other langs to thrive, and it doesn't need to "die" even if other languages thrive. It is not a zero-sum game.

> If C++ dies Rust will have a hard time replacing its GCV/LLVM backends.

> Cranelift as it stands today won't do it.

You're comparing a 20 year old project (LLVM) with a 4 year old project (cranelift) that have different goals. It's like comparing Rust and Python, or Fiat and Cannondale: they have some similarities, but any comparison is gonna be stretched beyond use.

Well, most Rust vs C++ comments, like the one I was replying to, tend to lack a perspective of what the market actually uses, and how Rust is dependent on C++ toolchains (at least for now), so.

LLVM in Rust seems actually plausible, there are some Rust ideas that probably feel very natural indeed to LLVM core people, in particular as I understand it the niche trick, where Rust knows the valid bits for type A and type B don't overlap, so, it can fit them both in whichever was the largest (e.g. Option<NonZeroUsize>), is something LLVM does a lot in its own internals.

The problem isn't the language, rather the volume of contributions.

Last year, LLVM has reached Linux kernel level of contributions from researchers and compiler vendors.

LLVM in Rust won't have that, and no one is going to rewrite such a massive compiler building infrastructure.

Then we have all the companies that building tooling on top of it, and everything related to the development process that relies on how LLVM is implemented.