That's weird though, right? There's no guarantee that Darwin won't vend more APIs that aren't C interfaces in future (it already has some, afaict). Similarly importing WinSDK on Windows, I'd imagine, or Android on Android.
So what's the unifying principle behind what's imported here versus not on the various platforms?
None, that's what I tried to get at above. Each platform implementer has just thrown in whatever they wanted to each overlay, so this would just be a way to replace the import chain shown above with a single import. The ship has sailed on making these platform overlays consistent, if it ever was possible because the underlying C headers never were too, as Ian says.
So, if this feature is explicitly not limited to C headers, then anything mentioning "C" is kind of a misnomer, no?
Should we just consider making System responsible for re-exporting the platform APIs?
I think that might be reasonable. An alternative would be CLibrary perhaps.
What I was getting at is System in the name is unfortunate, because it may be that the user wishes to use a non-system C runtime and so, how would they bring that library in.
This makes me wonder if on Windows, it should then also pull in WinSDK, which is the Windows' analogue to Darwin.
I think it may be limited to C headers on most platforms, but I'm not sure. My point was that there's no real principle behind what has gone in these platform overlays: that will have to wait on @al45tair's linked import C99 idea getting implemented, or something similar.
He included WinSDK in the OP.
FWIW, a similar crate in Rust is just named libc and contains the various extensions found in the Darwin module that aren't strictly libc APIs, like mach_port_t, copyfile(), etc.
So if we end up going in this direction, there's reasonable precedent to use a well-worn name like Libc, even if it's not an exact match. That seems somewhat better than inventing an awkward new name that isn't related to any of the underlying modules.
Regarding Windows, it looks like Rust's libc does not include Windows APIs equivalent to what WinSDK would bring in. I'm not a Windows user so I don't have skin in the game here, but having something like import Libc or import CSystem make functions like MessageBoxA available on Windows feels overly broad.
I definitely prefer SystemC, though SystemC exists and at least from a quick search online looks like it's used in the chip prototyping world, and I'm amused that isn't actually C, it's a collection of C++ types.
We need a way to describe a collection of C headers that the system ships its APIs in. That usually includes a C stdlib, C headers for working with the kernel, and C headers for working with the system. (elf.h comes to mind). This has been a pretty big bleeding point for anyone doing any sort of cross-platform or new platform bring-up. To the extent that folks will skip importing the platform-specific module at all, break modularization and create their own header that pulls in the bits they need, like Swift System has already done with the CSystem module:
module CSystem {
header "CSystemLinux.h"
header "CSystemWASI.h"
header "CSystemWindows.h"
export *
}
#ifdef __linux__
#include <sys/epoll.h>
#include <sys/eventfd.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <sys/sysinfo.h>
#include <sys/timerfd.h>
#include <sys/types.h>
#include <errno.h>
#include <fcntl.h>
#include <pthread.h>
#include <sched.h>
#include <unistd.h>
#endif
@ian-twilightcoder, I'm not sure if this is an endorsement for the CSystem name, or an argument against it to avoid a naming collision?
Anyway, this is bad. I have no idea how well it plays with the platform import towers scattered across the codebase:
#if SYSTEM_PACKAGE_DARWIN
import Darwin
#elseif os(Windows)
import CSystem
import ucrt
#elseif canImport(Glibc)
@_implementationOnly import CSystem
import Glibc
#elseif canImport(Musl)
@_implementationOnly import CSystem
import Musl
#elseif canImport(WASILibc)
import WASILibc
#elseif canImport(Bionic)
@_implementationOnly import CSystem
import Bionic
#else
#error("Unsupported Platform")
#endif
On the topic of Swift System, the name conveys that it's Swiftified. I think we want to reserve the pretty names for the well-designed, ergonomic, and safe modules. CSystem or SystemC is a bit clearer that you're going off the happy path. You're dealing with something closer to the raw C headers, so the APIs may not be perfectly ergonomic and guarantees may not be as strong as we would hope for normal Swift.
I think the unifying theme here is that we need a way to drill down to something that is as close to the raw C headers exposed by the system so that we can implement the porcelain layers above without limiting it purely based on the name of the platform since forking the entire ecosystem doesn't scale. Sometimes those C headers do things that don't play nicely with the clang-importer and so adding APINotes and maybe a few Swift files to overlay the underlying C API. I don't think that detracts from the spirit of providing raw access to the C interfaces to the system.
Hm. I think the reason to have a generic name is that there are plenty of APIs that will be the same across platforms:
If there's anything that's only available on one OS, like OSAtomic on Apple platforms (import os.atomic), it's already going to be guarded at the use site. Having to guard the import too isn't really an extra cost.
How much does this actually help? I'm not sure. I still think we'll end up wanting to take all of Darwin (which includes things like uuid.h), but WinSDK feels like it's on the borderline, since most of that is not APIs that someone can use in a platform-independent way (even if they were writing in C). Unfortunately CStandardAndCommonExtensions is a bit too unwieldy for a module name. :-P
Does "all of Darwin" include the stuff you get if _GNU_SOURCE is defined? What about __STDC_WANT_IEC_60559_BFP_EXT__? Or any of the other numerous defines that are used to control what exactly the Darwin/Glibc/etc headers actually expose and do not play nicely with modules?
The more I think about it, the more I'm convinced that we really shouldn't be pushing people to use these interfaces directly and Swift System should define Swift-native bindings for everything.
Yes, but that's not an answer. System will always lag behind the platform libraries, and I can't say I have much confidence in it replacing everything defined in C given how it's been going. You could still say "this isn't worth it" on the grounds that the APIs System won't cover won't be multiplatform anyway, but I don't really believe it. People have wanted this since we first released Linux support.
I don't think we should push people to use these interfaces, but sometimes strdup really is the correct API and you should be able to import it more easily than a pile of conditionals.
That's a fantastic example: I don't believe that strdup has ever been the correct API in any situation. At best it's a performance hazard, more often it's a nasty security bug waiting to happen. I don't want anyone to use it from C, much less from Swift.
On the contrary. The API system covers are not generally multiplatform and that's fine. (System is not a platform abstraction layer. It exists to faithfully bind platform API with Swift language conventions.)
System will always lag behind the platform libraries
Given that additions to platform C headers are generally behind macros you have to define before including them to avoid breaking source compatibility, the proposed module here would also lag behind (and possibly never catch up) as well. We still don't define _GNU_SOURCE when we import the Linux or Darwin C headers by default.
The precise time where strdup is useful is when calling a C API that accepts ownership of a malloc-managed C string. You could build this yourself out of calloc and Span copying, but that would be less clear than strdup(mySwiftString).
…though now that I've written it out, it would indeed be faster to use Swift's known length rather than remeasuring. Sigh. But you still have to remember to null-terminate.
When framed this way, the name that comes to mind is System. It might be interesting to consider a clang module by that name, which is shadowed by the Swift module. import System would import the Swift module which does an @_exported import System forwarding to the clang module. This gives us the nice name for both the Swift side and the C side. It also makes it clear what is being imported (the system's interfaces - kernel headers, standard library, and the rest of the system).
I guess part of the question is, does the new module supplant this? If so, it seems like the name has been selected. It certainly feels like it is meant to be for the same purpose, so it would make sense to continue using the name even if the content evolves.
Nobody is pushing it, but sometimes it is the only option available to those who know what they're doing, as Jordan says. As such, the discussion here on better names is likely wrong-headed, as we don't want devs reaching for the underlying platform C overlays unless they have to, which is why I suggested more niche names for this import in the past pitch threads linked above.
To be clear, I'm not saying that it should be impossible to import these headers; if nothing else, we need to import them to implement System.