Minor nitpick but it does not have seamless interfacing with anything other than Objective C.

C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first.

This is really no different than most other languages.

What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.

My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0].

But the C++ story is what you’ve described above.

[0] https://developer.apple.com/documentation/swift/imported_c_a...

and

https://developer.apple.com/documentation/swift/imported_c_a...

I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.)

There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875

I was thinking of Objective-C++ which can freely call into C++.

Swift seems to be one step removed from that. I guess you would have to write an Objective-C to Objective-C++ bridge to then use from Swift, ugh.

obj-c is a direct superset of c, so that interop already requires plain c capabilities right out of the box

and afair obj-c interrop is only available/supported on apple platforms

Swift can interface with C++? I've just done some googling but I cannot find any documentation at all relating to C++ interop. I make no assumption that I'm right but all I can see is interop via a C API

Seamless in my mind is what D has where name mangling, templates, and classes all work on Windows, Linux (possibly MacOS - I don't have one). Does swift have any of that?

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

Swift has great C interop for a language that is not a C superset, but C++ interop is at best a thing you can theoretically do. In practice c++ interop is usually done via a wrapper.