Frequently Asked Questions #18
Description
Why import SystemPackage instead of import System?
It's a workaround for current compiler limitations. If you have a binary System module available, as we do on Darwin and might have on other platforms in the future, then a System module from a package would conflict with that.
In the future the compiler might support module namespaces, which would allow us to name the module System in a package namespace distinct from one in a SDK or toolchain namespace. Alternatively or additionally, we might ship a binary System module for all platforms, in which case the package build would exist strictly for backwards deployment or prototyping.
Why are @available directives commented out?
This is due to language/tooling issues. We'd like the ability to add availability based on conditional compilation for ABI-stable builds of Swift System while not adding availability for package builds (i.e. a source dependency). For now, we include, but comment out, the availability declarations matching what has already been shipped in binary releases.
Why so many struct and no enums?
Swift struct gives us control over the layout (binary representation) of our types to an extent that enums do not. This is why types such as Errno and FileDescriptor.SeekOrigin are nominally structs, even though their API is more enum-like.
Swift enums are also exhaustive. This allows for exhaustive switching in user code, but there is no way to retroactively add, rename, alias, or fix cases. Swift’s open enums allows for extensibility, but can no longer be exhaustively switched over, providing effectively the same API experience as our enum-like nominal structs. Without layout control, there are fewer tools to change or extend the API/ABI surface with either enum or open enum, since the cases are the representation.