I was watching a video the youtube algorithm recommended to me, a reposted twitch stream about someone coming at Swift fresh. After trying examples from the tour, this person tried to find info on C interoperability. He was initially obsessed with searching "ffi" and was finding nothing, and then after searching the web he was only getting results of dubious quality and completeness.
I thought I could maybe find the documentation knowing more about what I'm looking for. But after a few searches through the documentation I was coming up fairly empty as well.
There should be an easy high-level section of the documentation, a guide showing minimal steps to call a C function or use an exported struct just with swiftc, then with Package.swift, and from there link to more details for Objective-C, C++, and other language interoperability.
I recently set up some C bindings for the first time and quickly figured out that rather than documentation looking at other projects and seeing what they do was the way forward. Which is a shame, because the foreign language binding story is a great selling point for Swift, but it does seem to be portrayed in a "we have excellent ways of binding to C and C++! It's in the back somewhere" gestures vaguely kind of manner.
I guess my question is, is this documentation written and just needs to be better surfaced, or do we need to write it?
To be fair, they just didn't read the error message about needing to use subfolders inside the Sources folder when having multiple targets in Package.swift, otherwise they could've got it working easily.
while i imagine there will be some folks who will experience âcorporate culture shockâ listening to his stream, having watched the video to the end i got the sense that this is a very intelligent person who in 30 minutes of fiddling around with a language that was completely alien to him, still managed to teach me a few techniques that i never knew in nine years of using Swift.
the sliding door moment for him was the way that swift package init generates the example project directly under Sources/ instead of in a subfolder as would be necessary in a multi-target project. i watched the moment when swift package init generated that bad layout for him and winced because, well, how was a newcomer supposed to know it was wrong? he did the entirely reasonable thing of synthesizing two âofficialâ sources of information and became very confused when they contradicted one another.
i also thought it was very illuminating the way that, in ten minutes, one of the viewers of his live stream put together an example project that was more helpful than anything else on Google, including âofficialâ documentation that was laboriously written by committee over the course of many months. overall, lots of lessons for us to absorb.
if i have time this week, iâll put together a transcript of his journey with the profanity toned town, as i think there is a lot of critical insights in his video that i worry will be ignored because of his particular speaking style.
It didn't matter, because he didn't really want to get it to work with SwiftPM. Because he didn't want to use SwiftPM in the first place. That's why he didn't bother carefully reading the error message nor the very long documentation.
All he wanted to know was how to use modulemap, which I absolutely agree should be the very first line of any Swift/C interop document. Not an explanation on how to set up SwiftPM.
Like, I rather like SwiftPM. And yet I agree it shouldn't be represented as if it's the only option. It sort of reminds me how much of the Android documentation starts with the assumption that you're working in Android Studio, and you have to jump through several hoops until it tells you how to just build with gradle (i.e. The only real option if working out of Docker).
The only reason I even know modulemap is a thing is from reading the Foundation source code. It really should be clearly documented.
I watched that whole stream a while ago, and one thing that really stood out to me was the up-front rejection of using SPM, or anything like it.
The C ecosystem (or lack-thereof, really) is infamous for its hand-rolled bash scripts, Makefiles, etc. to make one-off bespoke build systems for every project. Each with a different way to specify the target architecture (if that's even possible), debug mode (if even implemented), etc. Coming into Swift and SPM with that mentality just completely falls on its face. In fairness, it's completely possible (since SPM is "just" wrapping LLVM), but it's a maze of compiler flags and switches. Not unlike the C case, but less familiar to a C dev.
Personally, I wouldn't be too concerned about supporting this usage style. Compiling programs from multiple languages requires lots of metadata, which I think is far better off being standardized in something like Package.swift+module.modulemap, than it is to expect people to write all the equivalent compiler switches by hand.
First of all because it really shows some strengths of the Swift language. So many concepts came natural to the creator without them needing to look things up in the documentation.
I also enjoyed the jabs they took on the ecosystem and on SPM. Not because I share those pain points since I come from an iOS developer background, but I still think that they are right:
SPM is an abstraction on top of the compiler, and using the compiler and linker manually - and perhaps more easily than today - would be a strength.
And SPM is not the only build tool that you can use. I am playing with embedded Swift that builds using CMake, so understanding the level below SPM is useful.
I totally get that the language has different priorities and perhaps primarily makes it easy to use from Xcode and using SPM, but opening up the world to âtinkerersâ and people who want to understand the layers of abstraction is a really noble goal.
This is a critical use case that will be particularly common when adding Swift to an existing codebase. Swift (the language) cannot assume that SwiftPM is driving the compile-and-link process for the whole project. While SwiftPMâs project file format is well-documented and can be generated by other tooling, Iâm not sure that it is wise to require other build tools to puppet SwiftPM instead of invoking the compiler directly.
