C++ doesn't have a stable ABI, so if you target a C++ symbol manually like this, as soon as the compiler revs, to say, C++20, the ABI will change and you'll get a linker error.

Also, this may work for simple C++ methods, but once you cross over into vtable territory, you're going to be in a world of hurt.

Also as far as interoperability, I just don't see a smooth path forward between Swift and C++. Philosophically, much of the C++ code you write ends up compiling away or building specialized generated code at compile time. Anything written in C++17 and newer will also have a lot of constexpr code that generates immutable results baked into the final output.

I'd say, wrap your C++ in a simple C API and expose that to Swift (same would apply to Go/Rust or any other language honestly).

Hot take: ABI stability is overrated. How often do you need to relink specifically without recompiling everything? As an OS packager, it's no big deal to rebuild everything depending on a C++ shared library when that library is updated. For self-contained binary distributions, statically linking the C++ library or putting the shared objects together works fine still.

vtables are always a pain, but I think the Swift team had some cool ideas about vtables and other dynamic stuff across dynamically linked shared objects..

upd: https://gankra.github.io/blah/swift-abi/ this

A good build system would solve those problems. Yes a C wrapper is way easier.

Stable C++ ABI depends on implementation, it’s not inherent to the language.

Eek. I've done it but not exactly seamless as implied above! (feels Like using a landmine as a baking scale)

What issues did you run into?

I've only ever done it out of curious laziness but it's one of those things where it's theoretically clean enough to do right but if you do it wrong you might be fixing it all day. If something changes downstream or you make a mistake at 9AM you can end up with subtle non-failing garbage everywhere.

The only way I would do it and trust it, would be if the binding is generated and tested (separately) automatically, but at that stage why not just write one with a proper ABI.

Good luck instantiating and using classes if you do it that way. You pretty much have to reimplement the itanium abi in whatever language you're using (hint: if your language doesn't already support it, then even implementing it in assembly would be easier).