The Swift standard library, along with its tests and inline documentation, are a part of the main Swift repository.
Standard Library Preview Package
The Standard Library Preview package provides early access to new additions to the standard library. When new standard library APIs that can be implemented as a standalone library are accepted through the Swift Evolution process, they are published as individual packages and included in the preview package, which acts as an umbrella library. The preview package currently includes the following individual package:
|SE0270_RangeSet||Operations on noncontiguous subranges of collections, such as
Standard Library Design
The Swift standard library encompasses a number of data types,
protocols and functions, including fundamental data types (e.g.,
Double), collections (e.g.,
Dictionary) along with
the protocols that describe them and algorithms that operate on them,
characters and strings, and low-level primitives (e.g.,
UnsafeMutablePointer). The implementation of the standard library
resides in the
stdlib/public subdirectory within the Swift
repository, which is further subdivided into:
Standard library core: The core of the standard library (implemented in stdlib/public/core), including the definitions of all of the data types, protocols, functions, etc.
Runtime: The language support runtime (implemented in stdlib/public/runtime), which is layered between the compiler and the core standard library. It is responsible for implementing many of the dynamic features of the language, such as casting (e.g., for the
as?operators), type metadata (to support generics and reflection), and memory management (object allocation, reference counting, etc.). Unlike higher-level libraries, the runtime is written mostly in C++ or (where needed for interoperability) Objective-C.
SDK Overlays: Specific to Apple platforms, the SDK overlays (implemented in stdlib/public/Darwin) provide Swift-specific additions and modifications to existing Objective-C frameworks to improve their mapping into Swift. In particular, the
Foundationoverlay provides additional support for interoperability with Objective-C code.
The Swift standard library is written in Swift, but because it is the lowest-level Swift code in the stack—responsible for implementing the core data types on which other Swift code is built—it is a bit different from normal Swift code. Some of the differences include:
Access to compiler builtins: The
Builtinmodule, which is only generally accessible to the standard library, provides compiler builtin functions (e.g., to directly create SIL instructions) and data types (e.g., “raw” pointers, primitive LLVM integer types) needed to implement the data types that are fundamental to programming in Swift.
Visibility is often managed by convention: Standard library declarations often need to have greater visibility than one would generally like, due to the way in which the standard library is compiled and optimized. For example,
privatemodifiers are never used. More importantly, it is common to need to make something
publiceven when it is not intended as part of the public interface. In such cases, one should use a leading underscore to indicate that the public API is meant to be private. The policy for access control in the standard library is documented in docs/AccessControlInStdlib.rst.
Repetitive code uses gyb: gyb is a simple tool for generating repetitive code from a template that is used often in the standard library. For example, it is used to create the definitions of the various sized integer types (
Int64, etc.) from a single source.
Testing is tightly coupled with the compiler: The standard library and the compiler evolve together and are tightly coupled. Changes in core data types (e.g.,
Int) can require compiler-side changes, and vice-versa, so the standard library test suite is stored within the same directory structure as the compiler, in test/stdlib and validation-test/stdlib.