Standard Library

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 packages:

Package Description
SE0270_RangeSet Operations on noncontiguous subranges of collections, such as subranges(where:) and moveSubranges(_:to:), as well as the supporting RangeSet type.
SE0288_IsPower Extends BinaryInteger with an isPower(of:) method that returns whether an integer is a power of another.

Standard Library Design

The Swift standard library encompasses a number of data types, protocols and functions, including fundamental data types (e.g., Int, Double), collections (e.g., Array, 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! and 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 Foundation overlay 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 Builtin module, 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, private modifiers are never used. More importantly, it is common to need to make something public even 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 (Int8, Int16, Int32, 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., Array or 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.