Swift and C++ interoperability workgroup announcement
forums.swift.org
forums.swift.org
(To keep things organized, it would be great to have all the Q&A happen in one place, that's why I'm asking you post it in the forums. And remember, every question is valid, so don't be shy!)
I wish they'd start by standardizing something equivalent to "extern C" in Swift, so other languages can consume (wrapped) Swift libraries without having to implement support for the rather complicated Swift ABI.
There is the unofficial (but very relied upon) @_cdecl, if you're OK with needing to update your code if/when that eventually gets standardized. That attribute will take care of the calling convention difference for you.
https://github.com/apple/swift/blob/main/docs/ReferenceGuide...
The problem with such an ABI is getting people to use it, there's no single entity with enough power to enforce it.
I've thought of tackling the problem in another direction, making a simple C-like language (but slightly higher level) which uses the C ABI but with proper support for slices/strings/interfaces/errors/etc. and automatically produces wrapper code for mainstream languages (C++, Java, C#, Swift).
The wrappers wouldn't be idiomatic code in the host language, but they'd be directly usable, whereas right now wrapping a "C" library (even when produced by a higher level language) requires recovering all of the semantic information in an additional, library-dependent high-level wrapper.
For example, some SMT solvers expose quite nice C APIs, but to use them in say... Python, you'd need to use ctypes and a lot of low level code, which is why they go out of their way to expose wrapper APIs.
Some solvers like Yices2 have really low level Python wrappers, which mostly take care of the memory management, unpacking lists into a pointer and a length, and string conversions. There's no reason that couldn't be automated with a slightly higher-level than C language.
The language exists merely as a way of directly interfacing with the ABI, a way to get the libraries out the door so interest in the ABI exists (same as how VSCode made LSP popular).
The problem with doing Python <-> Swift is that you cannot (and should not) try to expose the entirety of Python and Swift to either side. So you need an "extern ABI" solution to expose your Swift code, except this is not built in to the Swift compiler so now you are in trouble.
If you go the external route you end up with SWIG, which is something you only use when you have no other option (CVC4 moved away from it for example).
Having a language that directly supports the ABI sidesteps this issue. All code written in the language works with the ABI directly so you get the wrappers for free without thinking about how to implement them. A lot of libraries are written in C directly for this very reason!
Once it becomes popular enough, languages would implement "extern ABI" directly, and can now talk to each other over it without the middleman. Same as how a compiler with LSP support can be used in editors that are not VSCode.
There is on Apple (XPC), Microsoft (COM/UWP) and Google (JNI, Android IPC, Fuchsia IDL), IBM (TIMI / Language Environments).
The problem are UNIX FOSS clones that lack such overlords.
That said, if IPC solutions count (which to me they don't), then the Linux standard would be D-Bus.
icrosoft went out of their way to support WinRT in Rust, because they want to use Rust themselves, it wasn't out of love.
Same applies with Google's support for Android IPC and Fuchsia IDL for Rust.
Naturally the platforms with headless management like UNIX FOSS clones will never adopt those solutions at scale, hence why nobody cares about D-BUS.
But I don't want to have to start a separate process and serialize data across a socket to call functions in every library that's packaged with my software, it's too expensive.
Even if the same IPC approach is used in-process and we accept the serialization costs (which is fine), why would library X use this approach and not another one? Specially if it needs to also run on macOS? Different IPC solutions per platform? Nah.
My point about Microsoft is that, had they not supported Rust themselves, it's likely nobody would have bothered with Rust projection for WinRT. That shows that even the OS devs lack the "strength" to enforce these things.
C is the glue everyone uses and will continue to be so for the foreseeable future.
Nope, it shows that Rust would be irrelevant for most Windows shops, and Microsoft wants to use Rust instead of C++ in certain workloads like they are already shipping on Azure IoT.
Same thing with Android and Fuchsia, good luck using your C glue there.
I think we're talking over each other. I'm not following your point. Do you believe WinRT is going to become the new standard for cross-language interoperability, even on Windows?
Libraries are either OS libraries, in which case something wraps the "platform ABI" and hides the interface (see SDL on Android for example), language specific (.NET libs are only for .NET languages), have custom tailored language A <-> language B binding generators (e.g. Shiboken to expose C++ Qt to Python), or expose a C API.
Even tools like Xamarin to expose Android APIs to .NET rely heavily on intermediate C glue because that's the only alternative (besides IPC, which is not desirable) to avoid running on the JVM.
COM with .NET metadata files + IInspectable in addition to IUnknown => WinRT
Since Windows Vista all major APIs are COM, you cannot avoid them unless you stuck in pre-historic Windows XP.
SDL on Android works, because Google has exposed the required APIs for game development to NDK, everything else requires a JNI call, or having Java code being called via Android IPC (binder).
Xamarin performance is quite bad versus Java/Kotlin, because they have to cross two layers to do anything meaningfull,
.NET => NDK => JNI and then for every Android event that gets triggered Java/Kotlin => JNI => .NET
Xamarin runs on ART (there is no JVM on Android) anyway, because the only kind of binaries that NDK allows for in proper Play Store applications are shared libraries loaded by Zygote process that owns ART.
Yes to talk to the platform you need to use the platform ABI, whatever that may be. OS devs obviously can force people use these ABIs to talk to the platform, otherwise it is literally impossible to talk to the platform. That's true on Linux as well btw, if I want native Desktop notifications across Desktop Environments I need to use the freedesktop standard (based on D-Bus).
I can ignore that, same way I can create a pseudo "notification" with the old Windows API instead of the proper WinRT APIs (heck, even Microsoft Teams does), but that's irrelevant because it's not what we're talking about.
This discussion started from a post on Swift <-> C++ interoperability. Swift has a stable ABI. C++ could directly implement that ABI, but Apple does not have the power to enforce that.
So what point are you trying to get across to me?
Apple has the power to enforce whatever they feel like doing on their own platform, that is why watchOS has a forked LLVM bitcode as executable format, regardless of how unstable the LLVM one is, C ABI matter zero there.
Just like they have a Safe C compiler for iBoot firmware, or have extended C language for lambdas (blocks).
Clang on Apple is different enough from upstream. that it warrants their own column on cppreference.
We are done here, there is no point getting across anyway.
Indeed this conversation is not helpful for either of us, I still don't know what you're trying to discuss. If you're under the impression that I claimed OS providers have no power over their own platform, I never once claimed that.
I claimed they cannot enforce their crap as a standard outside of their platform (sometimes not even on the platform, UWP died for all intents and purposes), which is demonstrably true.
Were you under the impression that I was not aware Microsoft Teams is an Electron app? And how its old non-native notifications work and how Electron wraps OS APIs that aren't web standards exposed in Chromium?
Honestly you've not only repeatedly insulted my intelligence in this thread, but you've also ignored all of my attempts at having an on-topic conversation. Normally that would make me label you as a troll, but you've had many valuable contributions across this website so I'll just assume you had a shitty day and leave it at that.
Does anyone know how c++ classes and struct will interact with ARC?
> But what about non-movable C++ classes that are not reference counted? This issue could be worked around by making retain and release operations on C++ classes be a no-op, and introducing an explicit "delete" operation, effectively making C++ class references in Swift equivalent to UnsafeMutablePointer.
There's some information about it in https://github.com/apple/swift/blob/main/docs/CppInteroperab... this is quite long though so there's likely a lot more information. This quote is apparently just one strategy they're considering? At least that's my take on reading it.
The original flag was "-experimental-cxx-interop", now it is "-enable-cxx-interop"
See here for examples of it in use, including interop with the C++ std library types:
for example, I can inject variables into the C preprocessor in my build settings and have a C header that defines constant strings with those variables, which I can then import directly into Swift as a module
It's usually as simple as calling data() on a vector or std::string (as well as having a function to return the length or size of the data buffer). And if you wrap your header file in the normal C externs, it shouldn't compile if you do things that are not allowed in C, if I remember.
But you are right it can be a lot of work if you have a large surface area. I try to stick to tight, focused APIs, and data is normal C structs which work fine in C++ as well.
I found it to be pretty neat, but it's very difficult to determine whats allowed to use outside the Apple ecosystem. The documentation is sporadic and there is only a reference manual. It makes me long for the Rust Book, with its tutorial style introductions. There are of course plenty of Swift tutorials out there, but they expect 1) you want to write an iOS App, and 2) you've never programmed a day in your life before.
The "standard library ecosystem" is very confusing. There's the actual language standard library, which is much like "core" in Rust. Then there's Apple's "Foundation" library, which is the more "batteries included" type standard library most people look for in a language. But "Foundation" isn't... straightfoward to understand. First of all, there's two completely separate implementations. On Apple platforms, you get the real Foundation, implemented in Objective-C with no source code available. On Linux, you get "swift-corelibs-foundation", which is fully open source and written entirely in Swift (really nice to look up what it is actually doing).
But swift-corelibs-foundation has a lot of missing features. To figure out if you're allowed to use something, you better be ready to look up the source code and see if its actually implemented on the Linux version. Or study a very long complicated markdown table in the github repo where they track what they've ported.
Want to develop on your MacBook but deploy to Linux? Better set up a complicated Docker environment so that you can actually see how your code will run with swift-corelibs-foundation. You _can't_ import or build against it on Apple platforms.
A lot of people learn a programming language by spending a lot of time reading the standard library. Well, it's nice that swift-corelibs-foundation is open source and publicly accessible and written in Swift. Unfortunately, it's not a great place to learn swift. Since it's a reimplementation of Foundation, which is itself a port of the Objective-C "Foundation Kit" library, its full of non-swifty concepts and ideas. There are, MOSTLY, more Swifty method implementations hanging off of the Foundation types, but there are also countless bits of API that take unsafe pointers or are fully deprecated and you must learn to ignore (looking at you, NSZone).
Learning Foundation is no easy task either. You can read the swift-corelibs-foundation source, of course. But since it's Swift, types are frequently re-opened and extended in other files so there's no one place to view the entirety of a type. There are the Apple developer docs, but theres no location where they list all the types in Foundation, or all the methods/properties on a type. The docs are handwritten, not generated from comments in the code. Apple recently released "DocC" to generate docs from swift libraries, so I'm hoping this one changes soon. There's the venerable swiftdoc.org which has generated documentation, but it only covers that "core" standard library. Also, certain symbols constantly 404 on it.
Thankfully, implementing a simple bytecode compiler doesn't require much beyond the standard library types. I still occasionally have to import Foundation, but its mostly just to get a single method here or there on a stdlib type, not to use some complicated NSObject based "class cluster".
I'm hopeful that good interop frameworks drive more folks to use the language outside Apple platforms, and real investment gets put into these issues. Don't get me started on XCTest on linux...
To give another example, even .NET with Microsoft going full steam with cross platform support, has lots of stuff that will never leave Windows.
Anyone using Swift for high load production workloads yet?
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.
A better C++ rust interop story is a critical piece for Rust's success IMO
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.
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...
If C++ dies Rust will have a hard time replacing its GCV/LLVM backends.
Cranelift as it stands today won't do it.
> 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.
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.