There continues to be a need for Swift code to directly use low level C interfaces provided by the operating system platform. These are exposed by the modules in stdlib/public/Platform including Glibc, CRT, WASILibc, Android, Musl, as well as Darwin in Apple SDKs. The fact that they all have different names requires cross platform code to start with an ever growing and tedious to maintain chain of #if os(...) and #if canImport(...).
#if canImport(Darwin)
import Darwin
#elseif canImport(Glibc)
import Glibc
#elseif canImport(Musl)
import Musl
#elseif canImport(Android)
import Android
#elseif canImport(WASILibc)
import WASILibc
#elseif canImport(EmscriptenLibc)
import EmscriptenLibc
#elseif os(Windows)
import CRT
import WinSDK
#else
#error("Unsupported platform")
#endif
This topic has come up a few times before in Pitch: The CStdlib module and [Pitch] Cross-Platform C Library Access , and mentioned in Using the C library from Swift: thoughts as well. Let's first examine what the current modules contain, which is a mix of the following
- C Standard Library
- POSIX
- Traditional low level BSD interfaces like <sys/queue.h>
- Other platform specific low level interfaces, such as <os/lock.h> on Apple platforms
Naming these modules after the platform is a poor convention for many reasons. It's ambiguous - what does Darwin mean? Everything in usr/include? Everything in libSystem? (It's neither one of those things.) Even the non-Apple platforms aren't perfectly descriptive, for example Glibc covers Linux kernel headers as well as glibc.
More importantly though, the disparate names obfuscate that there is actually a lot of overlap between these modules. e.g. If a Swift developer is looking for something from <string.h>, they have to discover all of the different system module names and carefully construct a onerous import chain at least 10 lines. All before writing any actual code! This is an inferior experience over C, where a simple #include <string.h> is all that's required.
I propose a standard name for the module covering the low level C interfaces provided by the operating system platform: CSystem. It's at approximately the same level as the System module, but is the C interfaces with minimal Swift overlay. Like the System module, and the headers CSystem covers, it is not generally portable. Swift code will require platform specific conditional compilation in the same places as equivalent C code. However, it can use a consistent and easy to remember import name, similar to how the C headers share consistent names even though they have different contents on different systems.
Why not CStdLib?
The modules contain more than the C Standard Library implementation, and in some cases the CStdLib implementation is incomplete.
Why not POSIX?
POSIX doesn't define everything that newer C standards define in the C Standard Library, so POSIX would be an incomplete description as well. Many of the covered systems do not have a full POSIX implementation either.
Why not separate CStdLib, CExtensions, POSIX, and other modules?
POSIX defines a lot of the C Standard Library headers, and lots of extensions to their contents as well. For example in POSIX the CStdLib header <stdio.h> is required to have functions that use ssize_t from the POSIX <sys/types.h> header. On a system that supports POSIX, it's not usually possible to separate its C Standard Library and POSIX implementations. Clang modules do not permit a header to be covered by multiple modules.
What about finer grained splits?
macOS 15.0/iOS 18.0 tried making modules for each C Standard Library header such as stdio_h and string_h. This allowed for precise names that mapped exactly to the C headers. However, it proved to be a rather significant compile time slowdown, clients had to manage a un-Swift-y long list of imports, and the technique was reverted back to larger modules in macOS 26.0/iOS 26.0. (The individual modules are still present, but they just import the larger modules.)
Why not stdlib?
The Swift runtime is referred to as the Standard Library Standard Library | Swift.org , so it would be confusing to call the OS platform interfaces stdlib.
What about SystemLibC, PlatformCLib, CPlatform, CC, libc, clib, C/C11/C23?
LibC/CLib suggest C Standard Library, or specifically the libc library, but these modules contain more than either of those things. C or C11 (or any other C standard name) has the same issue, just scoped to CStdLib. Platform is a term that isn't used in any common modules right now, Systemis the closer existing term. CC is evocative of the C compiler rather than a C library.
I agree that cross-platform Swift needs it. For implementers, I think it would help to generally scope out what a platform C overlay included here should have going forward, as so far these platform C overlays are just grab bags of whatever its implementer wanted, as you note. Perhaps tough to do given existing precedent, but may help 
