Frequently Asked Questions

### 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 `enum`s?

Swift `struct` gives us control over the layout (binary representation) of our types to an extent that `enum`s do not. This is why types such as `Errno` and `FileDescriptor.SeekOrigin` are nominally `struct`s, even though their API is more enum-like.

Swift `enum`s 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 enum`s allows for extensibility, but can no longer be exhaustively switched over, providing effectively the same API experience as our enum-like nominal `struct`s. 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.

The issue contains FAQ material about module naming, availability directives, and Swift structs versus enums, but names no documentation file or entry point. Start by locating the project's existing FAQ or documentation location and compare its structure with this content. Done means the intended questions and answers are published in the appropriate documentation location.

Written by the indexing model from the issue text.