Using the C library from Swift: thoughts

[Finagolfin]

@xwu

I see that many of these uses are non-trivially different from each other, including some that declare typealiases, so it's not clear to me actually how much mileage such an internal feature would get.

A Ctrl-F on "import FreeBSD" in that pull in my browser turns up 81 additions, and then manually going through them all turns up 3 that also define typealiases, don't see any other real differences. If the argument is that 3-5% of the time a conditional block that requires additional platform declarations is still required, the argument is lost.

@xwu

It's also not clear to me how many are using only C standard library facilities versus platform APIs—not that it clinches the point, but I see a lot of import Darwin and no import Darwin.C.

Yep, that's why I used the name _platformC instead, as the current overlays usually don't limit themselves to the libc alone, and most devs just grab whatever imports the largest platform API surface without bothering to scope it down. Considering all the module import leaks and nobody really sure what imports what, people just go big.

@xwu

I wonder what that breakdown would be for third-party uses of the import dance today--if people tend to customize the platforms recited and want the entire platform SDK for each, then the ask isn't some precursor that can ever be replaced with import C99.

There are certainly a few who customize the import wart, but that's no deal-breaker- this customized version with a typealias from the linked pull:

#if canImport(Darwin)
  import Darwin
  typealias JumpBuffer = Int32
#elseif canImport(Glibc)
  import Glibc
  typealias JumpBuffer = jmp_buf
#elseif canImport(FreeBSD)
  import FreeBSD
  typealias JumpBuffer = jmp_buf
#else
#error("Unsupported platform")
#endif

would simply turn into this instead:

import _platformC
#if canImport(Darwin)
  typealias JumpBuffer = Int32
#elseif canImport(Glibc) || canImport(FreeBSD)
  typealias JumpBuffer = jmp_buf
#else
#error("Unsupported platform")
#endif

As for how to replace it with C99 eventually, it would depend what you needed in each file/module. If you were only ever using C99 APIs in a file to begin with, you simply replace _platformC with C99. If it's both, I hope to see other fine-grained partitions of these platform APIs in the future too, so you can mix and match the imports that you need.

I added support for another platform libc to another programming language a decade ago, years before I ever got into Swift, and I wrote some crude scripts back then using libclang or some such tool to automate separating out all these platform C APIs in that language itself. This work is highly automatable, both on our end in implementing it in the Swift stdlib, and then later in helping devs transition to or choose what fine-grained imports to use, assuming they don't just choose the largest API surface like import Android does today.

For now, considering most multi-platform use of Swift is fairly new, a very broad _platformC that simply replaces the broad platform overlay import wart already being commonly used is a nice dev UX improvement, nothing more. Eventually, we can figure out how we give Swift devs tools to more finely import platform C APIs, hopefully through automated tools like swift-format or go fix that automate rewriting initially broad platform imports into fine-grained ones, as nobody wants to pick out all the submodules from these giant module maps by hand.