> Swift can interface with C++? I've just done some googling but I cannot find any documentation at all relating to C++ interop.

It is not there yet but it is actually being implemented on a native level. A quick Google gave me this. [0] [1] [2]

The approach is first-party than what you get with Rust's third-party crates and tools like bindgen, cxx, etc. Swift's C-interop approach is built-in and much more seamless and automated than bindgen's toggles and switches and creating them by hand in with cgo in Golang.

[0] https://github.com/apple/swift/blob/master/docs/CppInteroper...

[1] https://github.com/apple/swift/pulls?q=label%3A%22C%2B%2B+In...

[2] https://forums.swift.org/t/manifesto-interoperability-betwee...

It's being worked on, but it's nowhere near being usable in any sense. Very fundamental things still need to be tied down and decided, much less implemented.

Well I did say it's 'not there yet' and it is 'being implemented' so of course it is not yet usable as of now. Your same point could be said about Dart C/C++ FFI, Rust async-await, etc.

The parent comment I replied to said: "...I cannot find any documentation at all relating to C++ interop." and this some kind of "documentation" that is related to 'C++ interop'.

On most platforms, if you can interface with C, you can also interface with C++. Usually you have to find the mangled symbol in the C++ binary using a tool like nm, and treat it like a C function with whatever ffi you're using.

If you are targeting multiple platforms this can get tricky because the mangled C++ symbol will (probably) be different for each platform, which can be solved with a good build system

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