Изменения в Swift

As Swift Concurrency continues to mature it is becoming increasingly important to offer adopters tighter control over where exactly asynchronous work is actually executed.

We propose introducing helper methods for creating AsyncStream and AsyncThrowingStream instances which make the stream's continuation easier to access.

This proposal seeks to improve the usability of existing Objective-C libraries from Swift by reducing the negative impact forward declarations have on API visibility from Swift. We wish to start synthesizing placeholder types to represent forward declared Objective-C interfaces and protocols in Swift.

We propose to introduce a new type of structured concurrency task group: Discarding[Throwing]TaskGroup. This type of group is similar to TaskGroup however it discards results of its child tasks immediately. It is specialized for potentially never-ending task groups, such as top-level loops of http or other kinds of rpc servers.

This proposal introduces the ability to use if and switch statements as expressions, for the purpose of:

Resilient Swift libraries, such as the ones present in the SDKs for Apple's platforms, are distributed as dynamic libraries. Authors of these libraries use @available annotations to indicate the operating system version that a declaration was introduced in. For example, suppose this were the interface of ToastKit, a library that is part of the toasterOS SDK:

SE-0352 "Implicitly Opened Existentials" has a limitation that prevents the opening of an existential argument when the corresponding parameter is optional. This proposal changes that behavior, so that such a call will succeed when a (non-optional) existential argument is passed to a parameter of optional type:

The Clock protocol introduced in Swift 5.7 provides a way to suspend until a future instant, but does not provide a way to sleep for a duration. This differs from the static sleep methods on Task, which provide both a way to sleep until an instant or for a duration.

The implementation of the result builder transform (introduced by SE-0289) places a number of limitations on local variable declarations in the transformed function. Specifically, local variables need to have an initializer expression, they cannot be computed, they cannot have observers, and they cannot have attached property wrappers. None of these restrictions were explicit in the SE-0289 proposal, but they are a de facto part of the current feature.

Swift's sorting algorithm was changed to be stable before Swift 5, but we've never updated the documentation to provide that guarantee. Let's commit to the sorting algorithm being stable so that people can rely on that behavior.

The types in the UnsafeMutablePointer family typically require manual management of memory allocations, including the management of their initialization state. Unfortunately, not every relevant type in the family has the necessary functionality to fully manage the initialization state of the memory it represents. The states involved are, after allocation:

This proposal is to add conformance to the protocol CustomDebugStringConvertible to AnyKeyPath.

Integer literals in Swift source code can express an arbitrarily large value. However, types outside of the standard library which conform to ExpressibleByIntegerLiteral are restricted in practice in how large of a literal value they can be built with, because the value passed to init(integerLiteral:) must be of a type supported by the standard library. This makes it difficult to write new integer types outside of the standard library.

Over time, Swift has introduced a number of new attributes to communicate additional information in source code. Existing code can then be updated to take advantage of these new constructs to improve its behavior, providing more expressive capabilities, better compile-time checking, better performance, and so on.

As of SE-0269, implicit self is permitted in closures when self is written explicitly in the capture list. We should extend this support to weak self captures, and permit implicit self as long as self has been unwrapped.

This proposal describes Regex's rich Unicode support during regex matching, along with the character classes and options that define and modify that behavior.

Swift 6 is accumulating a number of improvements to the language that have enough source-compatibility impact that they could not be enabled by default in prior language modes (Swift 4.x and Swift 5.x). These improvements are already implemented in the Swift compiler behind the Swift 6 language mode, but they are inaccessible to users, and will remain so until Swift 6 becomes available as a language mode. There are several reasons why we should consider making these improvements available sooner:

Specifying the type arguments to a generic type in Swift is almost always written in angle brackets, such as Array. Extensions are a notable exception, and if you attempt to extend Array, the compiler reports the following error message:

Since their introduction in SE-0244, opaque result types have become a powerful tool of type-level abstraction that allows library authors to hide implementation details of their APIs.

SE-0346 introduced the concept of primary associated types to the language. This document proposes to adopt this feature in the Swift Standard Library, adding primary associated types to select existing protocols. Additionally, we provide some general API design recommendations that protocol authors may find helpful when adding support for this language feature.

The Swift standard library's string processing algorithms are underpowered compared to other popular programming and scripting languages. Some of these omissions can be found in NSString, but these fundamental algorithms should have a place in the standard library.

This proposal describes a convention for writing a new form of sample code called snippets. Snippets are short, single-file examples that can build and run from within a Swift package, with access to other code within that package, and can be used in a variety of ways.

A regex declares a string processing algorithm using syntax familiar across a variety of languages and tools throughout programming history. We propose the ability to create a regex at run time from a string containing regex syntax (detailed here), API for accessing the match and captures, and a means to convert between an existential capture representation and concrete types.

We propose the introduction of regex literals to Swift source code, providing compile-time checks and typed-capture inference. Regex literals help complete the story told in Regex Type and Overview.

Existential types complement the Swift type system’s facilities for abstraction. Like generics, they enable a function to take and return multiple possible types. Unlike generic parameter types, existential types need not be known up front when passed as inputs to a function. Further, concrete types can be erased (hidden behind the interface of a protocol) when returned from a function. There has been a flurry of activity in this space withSE-0309 unblocking the remaining restrictions on using protocols with associated types as existential types, and SE-0346 paving the way for a lightweight constraint syntax for the associated types of protocols. Building directly upon those ideas, this proposal seeks to re-use the syntax of lightweight associated type constraints in the context of existential types.

Existential types in Swift allow one to store a value whose specific type is unknown and may change at runtime. The dynamic type of that stored value, which we refer to as the existential's underlying type, is known only by the set of protocols it conforms to and, potentially, its superclass. While existential types are useful for expressing values of dynamic type, they are necessarily restricted because of their dynamic nature. Recent proposals have made existential types more explicit to help developers understand this dynamic nature, as well as making existential types more expressive by removing a number of limitations. However, a fundamental issue with existential types remains, that once you have a value of existential type it is very hard to use generics with it. Developers usually encounter this via the error message "protocol 'P' as a type cannot conform to itself":

Declarative string processing aims to offer powerful pattern matching capabilities with expressivity, clarity, type safety, and ease of use. To achieve this, we propose to introduce a result-builder-based DSL, regex builder, for creating and composing regular expressions (regexes).

Swift strings provide an obsessively Unicode-forward model of programming with strings. String processing with Collection's algorithms is woefully inadequate for many day-to-day tasks compared to other popular programming and scripting languages.

Swift does not currently provide a clear way to load data from an arbitrary source of bytes, such as a binary file, in which data may be stored without respect for in-memory alignment. This proposal aims to rectify the situation, making workarounds unnecessary.

It's currently impossible to use a default value expression with a generic parameter type to default the argument and its type:

As a step toward the goal of improving the UI of generics outlined in Improving the UI of Generics, this proposal introduces a new syntax for conforming a generic parameter and constraining an associated type via a same-type requirement.

Optional binding using if let foo = foo { ... }, to create an unwrapped variable that shadows an existing optional variable, is an extremely common pattern. This pattern requires the author to repeat the referenced identifier twice, which can cause these optional binding conditions to be verbose, especially when using lengthy variable names. We should introduce a shorthand syntax for optional binding when shadowing an existing variable:

With the recent introduction of actors to the language, Swift gained powerful and foundational building blocks for expressing thread-safe concurrent programs. Actors guarantee thread-safety thanks to actor-isolation of mutable state they encapsulate.

Bringing concurrency to top-level code is an expected continuation of the concurrency work in Swift. This pitch looks to iron out the details of how concurrency will work in top-level code, specifically focusing on how top-level variables are protected from data races, and how a top-level code context goes from a synchronous context to an asynchronous context.

Swift's syntax for generics is designed for generality, allowing one to express complicated sets of constraints amongst the different inputs and outputs of a function. For example, consider an eager concatenation operation that builds an array from two sequences:

The Swift concurrency model allows tasks to resume on different threads from the one they were suspended on. For this reason, API that relies on thread-local storage, locks, mutexes, and semaphores, should not be used across suspension points.

Swift does not allow multiple modules in a program to share the same name, and attempts to do so will fail to build. These name collisions can happen in a reasonable program when using multiple packages developed independently from each other. This proposal introduces a way to resolve these conflicts without making major, invasive changes to a package's source by turning a module name in source into an alias, a different unique name.

SE-0306, which introduced actors to Swift, states that async functions may be actor-isolated, meaning that they formally run on some actor's executor. Nothing in either SE-0306 or SE-0296 (async/await) ever specifies where asynchronous functions that aren't actor-isolated run. This proposal clarifies that they do not run on any actor's executor, and it tightens up the rules for sendability checking to avoid a potential data race.

Swift 5.5 introduced mechanisms to eliminate data races from the language, including the Sendable protocol (SE-0302) to indicate which types have values that can safely be used across task and actor boundaries, and global actors (SE-0316) to help ensure proper synchronization with (e.g.) the main actor. However, Swift 5.5 does not fully enforce Sendable nor all uses of the main actor because interacting with modules which have not been updated for Swift Concurrency was found to be too onerous. We propose adding features to help developers migrate their code to support concurrency and interoperate with other modules that have not yet adopted it, providing a smooth path for the Swift ecosystem to eliminate data races.

With the recent introduction of actors to the language, Swift gained powerful and foundational building blocks for expressing thread-safe concurrent programs. This proposal is the first in a series of proposals aiming to extend Swift's actor runtime with the concept of distributed actors, allowing developers leverage the actor model not only in local, but also distributed settings.

Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of active harm by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental limitation of value-level abstraction. This proposal makes the impact of existential types explicit in the language by annotating such types with any.

This proposal introduces some quality-of-life improvements for UnsafePointer and its Mutable and Raw variants.

The function withMemoryRebound(to:capacity:_ body:) executes a closure while temporarily binding a range of memory to a different type than the callee is bound to. We propose to lift some notable limitations of withMemoryRebound and enable rebinding to a larger set of types, as well as rebinding the memory pointed to by raw memory pointers and buffers.

SE-0303 introduced the ability to define build tool plugins in SwiftPM, allowing custom tools to be automatically invoked during a build. This proposal extends that plugin support to allow the definition of custom command plugins — plugins that users can invoke directly from the SwiftPM CLI, or from an IDE that supports Swift Packages, in order to perform custom actions on their packages.

SE-0302 introduced the Sendable protocol, including Sendable requirements for various language constructs, conformances of various standard library types to Sendable, and inference rules for non-public types to implicitly conform to Sendable. SE-0302 states that the unsafe pointer types conform to Sendable:

The concepts of time can be broken down into three distinct parts:

An opaque result type may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in "structural" positions.

I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.

SE-0303 introduced the ability to define build tool plugins in SwiftPM, allowing custom tools to be invoked while building a package. In support of this, SE-0303 introduced a minimal initial API through which plugins can access information about the target for which they are invoked.

C has special rules for pointer aliasing, for example allowing char * to alias other pointer types, and allowing pointers to signed and unsigned types to alias. The usability of some C APIs relies on the ability to easily cast pointers within the boundaries of those rules. Swift generally disallows typed pointer conversion. See SE-0107 UnsafeRawPointer API. Teaching the Swift compiler to allow pointer conversion within the rules of C when invoking functions imported from C headers will dramatically improve interoperability with no negative impact on type safety.

Program setup generally occurs in the main function where developers expect to perform operations before other parts of the program are run. Objective-C, C++, and C have initializers that are run before the main entrypoint runs and can interact with Swift's concurrency systems in ways that are hard to reason about. In the Swift concurrency model, the developer-written asynchronous main function is wrapped in a task and enqueued on the main queue when the main entrypoint is run. If an initializer inserts a task on the main queue, that task may be executed before the main function, so setup is performed after initializer tasks are run.

This proposal introduces new Standard Library functions for manipulating temporary buffers that are preferentially allocated on the stack instead of the heap.

The current conformance of Swift's Dictionary to the Codable protocols has a somewhat-surprising limitation in that dictionaries whose key type is not String or Int (values directly representable in CodingKey types) encode not as KeyedContainers but as UnkeyedContainers. This behavior has caused much confusion for users and I would like to offer a way to improve the situation.

This proposal conforms Never to Identifiable to make it usable as a "bottom type" for generic constraints that require Identifiable.

Structured concurrency provides a paradigm for spawning concurrent child tasks in scoped task groups, establishing a well-defined hierarchy of tasks which allows for cancellation, error propagation, priority management, and other tricky details of concurrency management to be handled transparently.

Actors are a new kind of reference type that protect their instance data from concurrent access. Swift actors achieve this with actor isolation, which ensures (at compile time) that all accesses to that instance data go through a synchronization mechanism that serializes execution.

When Swift's type inference is unable to work out the type of a particular expression, it requires the programmer to provide the necessary type context explicitly. However, all mechanisms for doing this require the user to write out the entire type signature, even if only one portion of that type is actually needed by the compiler. E.g.,

The continuation types added in SE-0300 act as adaptors for synchronous code that signals completion by calling a delegate method or callback function. For code that instead yields multiple values over time, this proposal adds new types to support implementing an AsyncSequence interface.

The Swift actors proposal introduces the notion of actor-isolated declarations, which are declarations that can safely access an actor's isolated state. In that proposal, all instance methods, instance properties, and instance subscripts on an actor type are actor-isolated, and they can synchronously use those declarations on self. This proposal generalizes the notion of actor isolation to allow better control, including the ability to have actor-isolated declarations that aren't part of an actor type (e.g., they can be non-member functions) and have non-isolated declarations that are instance members of an actor type (e.g., because they are based on immutable, non-isolated actor state). This allows better abstraction of the use of actors, additional actor operations that are otherwise not expressible safely in the system, and enables some conformances to existing, synchronous protocols.

With Swift embracing asynchronous functions and actors, asynchronous code will be everywhere.

Nominal types such as classes, structs, and enums in Swift support computed properties and subscripts, which are members of the type that invoke programmer-specified computations when getting or setting them. The recently accepted proposal SE-0296 introduced asynchronous functions via async, in conjunction with await, but did not specify that computed properties or subscripts can support effects like asynchrony. Furthermore, to take full advantage of async properties, the ability to specify that a property throws is also important. This document aims to partially fill in this gap by proposing a syntax and semantics for effectful read-only computed properties and subscripts.

Swift allows one to use a protocol as a type when its requirements meet a rather unintuitive list of criteria, among which is the absence of associated type requirements, and emits the following error otherwise: Protocol can only be used as a generic constraint because it has 'Self' or associated type requirements. Our objective is to alleviate this limitation so as to impact only the ability to access certain members (instead of preemptively sealing off the entire protocol interface), and adjust the specified criteria to further reduce the scope of the restriction.

Swift has conditional compilation block #if ... #endif which allows code to be conditionally compiled depending on the value of one or more compilation conditions. Currently, unlike #if in C family languages, the body of each clause must surround complete statements. However, in some cases, especially in result builder contexts, demand for applying #if to partial expressions has emerged. This proposal expands #if ... #endif to be able to surround postfix member expressions.

I propose to extend the language and allow Double and CGFloat types to be used interchangeably by means of transparently converting one type into the other as a sort of retroactive typealias between these two types. This is a narrowly defined implicit conversion intended to be part of the existing family of implicit conversions (including NSType <=> CFType conversions) supported by Swift to strengthen Objective-C and Swift interoperability. The only difference between the proposed conversion and existing ones is related to the fact that interchangeability implies both narrowing conversion (Double -> CGFloat) and widening one (CGFloat -> Double) on 32-bit platforms. This proposal is not about generalizing support for implicit conversions to the language.

The Swift concurrency model intends to provide a safe programming model that statically detects data races and other common concurrency bugs. The Structured Concurrency proposal introduces a way to define concurrent tasks and provides data-race safety for functions and closures. This model is suitable for a number of common design patterns, including things like parallel maps and concurrent callback patterns, but is limited to working with state that is captured by closures.

This proposal extends SwiftPM binary targets to also support other kinds of prebuilt artifacts, such as command line tools. It does not in and of itself add support for non-Darwin binary libraries, although the proposed improvements could be a step towards such support.

async/await is a language mechanism for writing natural, efficient asynchronous code. Asynchronous functions (introduced with async) can give up the thread on which they are executing at any given suspension point (marked with await), which is necessary for building highly-concurrent systems.

This is a proposal for extensible build tools support in Swift Package Manager. The initial set of functionality is intentionally basic, and focuses on a general way of extending the build command graph through plugins.

A key goal of the Swift Concurrency effort is to “provide a mechanism for isolating state in concurrent programs to eliminate data races.” Such a mechanism will be a major progression for widely used programming languages — most of them provide concurrent programming abstractions in a way that subjects programmers to a wide range of bugs, including race conditions, deadlocks and other problems.

Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.

Using static member declarations to provide semantic names for commonly used values which can then be accessed via leading dot syntax is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of this syntax. This proposal aims to relax restrictions on accessing static members on protocols to afford the same call-site legibility to generic APIs.

Swift's async/await feature provides an intuitive, built-in way to write and use functions that return a single value at some future point in time. We propose building on top of this feature to create an intuitive, built-in way to write and use functions that return many values over time.

Swift's concurrency feature involves asynchronous functions and actors. While Objective-C does not have corresponding language features, asynchronous APIs are common in Objective-C, expressed manually through the use of completion handlers. This proposal provides bridging between Swift's concurrency features (e.g., async functions) and the convention-based expression of asynchronous functions in Objective-C. It is intended to allow the wealth of existing asynchronous Objective-C APIs to be immediately usable with Swift's concurrency model.

Modern Swift development involves a lot of asynchronous (or "async") programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.

Codable was introduced in SE-0166 with support for synthesizing Encodable and Decodable conformance for class and struct types, that only contain values that also conform to the respective protocols.

This proposal lets Swift Package authors declare targets as executable in the package manifest. This replaces the current approach of inferring executability based on the presence of a source file with the base name main at the top level of the target source directory.

Property Wrappers were introduced in Swift 5.1, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending where property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.

Swift Package Manager downloads dependencies using Git. Our proposal defines a standard web service interface that it can also use to download dependencies from a package registry.

This is a proposal for adding support for Package Collections to SwiftPM. A package collection is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these collections, search them via the swift package-collection command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package collections.

Swift historically supported the #available condition to check if a specific symbol is available for usage, but not the opposite. In this proposal, we'll present cases where checking for the unavailability of something is necessary, the ugly workaround needed to achieve it today and how a new #unavailable condition can fix it.

This proposal describes result builders, a new feature which allows certain functions (specially-annotated, often via context) to implicitly build up a result value from a sequence of components.

When the type of an expression is implied by the context, Swift allows developers to use what is formally referred to as an "implicit member expression," sometimes referred to as "leading dot syntax":

SE-0279 "Multiple Trailing Closures" threaded the needle between getting the syntax we wanted for multiple trailing closures without breaking source compatibility. One aspect of that compromise was to extend (rather than replace) the existing rule for matching a trailing closure to a parameter by scanning backward from the end of the parameter list.

In SE-0274, the core team accepted a proposal to change the behavior of #file. This proposal modifies that plan to transition into new behavior more gradually, treating it as a source break requiring a new language version mode to fully adopt.

Currently, variadic parameters in Swift are subject to two main restrictions:

This proposal adopts a C/C++-style weak concurrency memory model in Swift, describing how Swift code interoperates with concurrency primitives imported from C.

A Swift language feature for designating a type as the entry point for beginning program execution. Instead of writing top-level code, users can use the @main attribute on a single type. Libraries and frameworks can then provide custom entry-point behavior through protocols or class inheritance.

The aim of this proposal is to lift an existing restriction, which is that enum cases cannot participate in protocol witness matching.

This proposal builds on top of the Package Manager Resources proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.

Introduce the Float16 type conforming to the BinaryFloatingPoint and SIMDScalar protocols, binding the IEEE 754 binary16 format (aka float16, half-precision, or half), and bridged by the compiler to the C _Float16 type.

Currently, each catch clause in a do-catch statement may only contain a single pattern and where clause. This is inconsistent with the behavior of cases in switch statements, which provide similar functionality. It also makes some error handling patterns awkward to express. This proposal extends the grammar of catch clauses to support a comma-separated list of patterns (with optional where clauses), resolving this inconsistency.

Today, #file evaluates to a string literal containing the full path to the current source file. We propose to instead have it evaluate to a human-readable string containing the filename and module name, while preserving the existing behavior in a new #filePath expression.

This proposal introduces the ability for Swift package authors to conditionalize target dependencies on platform and configuration with a similar syntax to the one introduced in SE-0238 for build settings. This gives developers more flexibility to describe complex target dependencies to support multiple platforms or different configuration environments.

SwiftPM currently supports source-only packages for several languages, and with a very proscriptive build model which considerably limits exactly how the compilation of the source can be performed. While this makes packages consistent and to some extent "simple", it limits their use in several important cases:

Packages should be able to contain images, data files, and other resources needed at runtime. This proposal describes SwiftPM support for specifying such package resources, and introduces a consistent way of accessing them from the source code in the package.

Modify the rule that all uses of self in escaping closures must be explicit by allowing for implicit uses of self in situations where the user has already made their intent explicit, or where strong reference cycles are otherwise unlikely to occur. There are two situations covered by this proposal. The first is when the user has explicitly captured self in the closure's capture list, so that the following would compile without error:

Introduce two changes to didSet semantics -

This proposal aims to lift the restriction on attaching where clauses to member declarations that can reference only outer generic parameters. Simply put, this means the 'where' clause cannot be attached error will be relaxed for most declarations nested inside generic contexts:

SE-185 introduced synthesized, opt-in Equatable and Hashable conformances for eligible types. Their sibling protocol Comparable was left out at the time, since it was less obvious what types ought to be eligible for a synthesized Comparable conformance and where a comparison order might be derived from. This proposal seeks to allow users to opt-in to synthesized Comparable conformances for enum types without raw values or associated values not themselves conforming to Comparable, a class of types which I believe make excellent candidates for this feature. The synthesized comparison order would be based on the declaration order of the enum cases, and then the lexicographic comparison order of the associated values for an enum case tie.

We propose changing the Swift Evolution process to publish accepted proposals as individual SwiftPM packages, as well as a SwiftPreview package that bundles these proposal packages together. This group of packages will form the initial landing spot for certain additions to the Swift standard library.

This proposal suggests a new initializer for String that provides access to a String's uninitialized storage buffer.

This proposal introduces an Identifiable protocol, a general concept that is broadly useful— for diff algorithms, user interface libraries, and other generic code—to correlate snapshots of the state of an entity in order to identify changes. It is a fundamental notion that deserves representation in the standard library.

One of Swift's goals is to be a good language for libraries with binary compatibility concerns, such as those shipped as part of Apple's OSs. This includes giving library authors the flexibility to add to their public interface, and to change implementation details, without breaking binary compatibility. At the same time, it's important that library authors be able to opt out of this flexibility in favor of performance.

There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler (as we have done for lazy and @NSCopying), we should provide a general "property wrapper" mechanism to allow these patterns to be defined as libraries.

Swift provides a pleasant shorthand for short closures: if a closure contains just a single expression, that expression is implicitly returned--the return keyword can be omitted. We should provide this shorthand for functions as well.

We propose allowing static subscript and, in classes, class subscript declarations. These could be used through either TypeName[index] or TypeName.self[index] and would have all of the capabilities you would expect of a subscript. We also propose extending dynamic member lookup to static properties by using static subscripts.

This proposal introduces "statically" callable values to Swift. Callable values are values that define function-like behavior and can be called using function call syntax. In contrast to dynamically callable values introduced in SE-0216, this feature supports statically declared arities, argument labels, and parameter types, and is not constrained to primary type declarations.

This proposal attempts to enable stronger-typed version of the dynamic member lookup by extending functionality of an existing @dynamicMemberLookup attribute with key path based variants.

Early adopters of SIMD types and protocols have encountered a few missing things as they've started to write more code that uses them. In addition, there are some features we punted out of the original review because we were up against a hard time deadline to which we would like to give further consideration.

This proposal introduces the ability to use the key path expression Root.value wherever functions of (Root) -> Value are allowed.

String and related types are missing trivial and obvious functionality, much of which currently exists internally but has not been made API. We propose adding 9 new methods/properties and 3 new code unit views.

One of the most common API requests from performance-minded users of string is a way to get direct access to the raw underlying code units. Now that Swift 5 uses UTF-8 for its preferred encoding, we can provide this.

This proposal suggests a new initializer for Array and ContiguousArray that provides access to an array's uninitialized storage buffer.

This proposal is the first part of a group of changes we're considering in a design document for improving the UI of the generics model. We'll try to make this proposal stand alone to describe opaque return types, their design, and motivation, but we also recommend reading the design document for more in-depth exploration of the relationships among other features we're considering. We'll link to relevant parts of that document throughout this proposal.

This proposal aims to solve a simple outstanding problem with the way the Swift compiler currently synthesizes the memberwise initializer for structures by synthesizing default values for properties with default initializers.

SE-0180 introduced a computed variable and initializer surrounding the concept of an encodedOffset for serialization purposes. Unfortunately, that approach is flawed for its intended purpose and is commonly misused in ways that Swift 5 is more likely to expose. It is too late in the Swift 5.0 release to solve all existing problems, so we propose deprecating encodedOffset and introducing a targeted, semantics-preserving alternative.

This proposal describes additions to the standard library that provide an interchange format for diffs as well as diffing/patching functionality for appropriate collection types.

SE-0167 introduced Codable conformance for some types in the standard library, but not the Range family of types. This proposal adds that conformance.

This is a proposal for adding support for declaring some commonly used target-specific build settings in the Package.swift manifest file. As the name suggests, target-specific build settings are only applied to a particular target. SwiftPM also aims to support cross-target build settings that go across the target boundary and impart certain settings on a target's dependees, but this proposal is only concerned with the former type of build settings and the latter will be explored with a future proposal.

This proposal introduces two new methods, on Sequence and MutableCollection. These methods will allow generic code to make use of the withUnsafe{Mutable}BufferPointer idiom, as well as provide fast paths in the standard library for adopting types.

This is a proposal for adding support for specifying a per-platform minimum required deployment target in the Package.swift manifest file.

Swift's current error-handling, using throws, try, and catch, offers automatic and synchronous handling of errors through explicit syntax and runtime behavior. However, it lacks the flexibility needed to cover all error propagation and handling in the language. Result is a type commonly used for manual propagation and handling of errors in other languages and within the Swift community. Therefore this proposal seeks to add such a type to the Swift standard library.

This proposal recommends eliminating the associated type from Sequence, moving it up to start at Collection. Current customization points on Sequence returning a SubSequence will be amended to be extensions returning concrete types.

This proposal introduces a weakening of the existing Numeric protocol named AdditiveArithmetic , which defines additive arithmetic operators and a zero, making conforming types roughly correspond to the mathematic notion of an additive group. This makes it possible for vector types to share additive arithmetic operators with scalar types, which enables generic algorithms over AdditiveArithmetic to apply to both scalars and vectors.

This proposal removes four customization points from protocols in the standard library:

Swift's try? statement currently makes it easy to introduce a nested optional. Nested optionals are difficult for users to reason about, and Swift tries to avoid producing them in other common cases.

This proposal would expose a common subset of operations on the SIMD types supported by most processors in the standard library. It is based on Apple's module, which is used throughout Apple's platforms as the common currency type for fixed-size vectors and matrices. It is not a complete re-implementation; rather it provides the low-level support needed to import any such library, and tries to make a number of things much nicer in Swift than they are in C or C++.

String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the ExpressibleByStringInterpolation protocol has been deprecated since Swift 3. We propose a new design that improves its performance, clarity, and efficiency.

Add the ability to reference the identity key path, which refers to the entire input value it is applied to.

This is a proposal for enhancing the package resolution process to resolve the minimal set of dependencies that are used in a package graph.

This proposal adds var isEven: Bool, var isOdd: Bool, and func isMultiple(of other: Self) -> Bool to the BinaryInteger protocol. isEven and isOdd are convenience properties for querying the parity) of the integer and isMultiple is a more general function to determine whether an integer is a multiple of another integer.

This proposal augments the functionality implemented for proposal SE-0020 with the introduction of a new valid operator in compilation condition: "<". The aim is that the syntax #if swift(<4.2) is supported by the language.

@allevato (a co-author here) proposed Add Unicode Properties to Unicode.Scalar, which exposes Unicode properties from the Unicode Character Database. These are Unicode expert/enthusiast oriented properties that give a finer granularity of control and answer highly-technical and specific Unicody enquiries.

A dependency mirror refers to an alternate source location which exactly replicates the contents of the original source. This is a proposal for adding support for dependency mirroring in SwiftPM.

This proposal adds a combined filter/map operation to Dictionary, as a companion to the mapValues and filter methods introduced by SE-0165. The new compactMapValues operation corresponds to compactMap on Sequence.

This proposal is a follow-up to SE-0195 - Introduce User-defined "Dynamic Member Lookup" Types, which shipped in Swift 4.2. It introduces a new @dynamicCallable attribute, which marks a type as being "callable" with normal syntax. It is simple syntactic sugar which allows the user to write:

Extend Never so it conforms to Equatable and Hashable.

This proposal renames the confusing and misnamed DictionaryLiteral type to KeyValuePairs. This type is neither a dictionary nor a literal. It is a list of key-value pairs.

T(literal) should construct T using the appropriate literal protocol if possible.

This proposal introduces a compiler directive that is syntactically equivalent to the #if swift version check but checks against the version of the compiler, regardless of which compatibility mode it's currently running in.

We propose adding a number of properties to the Unicode.Scalar type to support both common and advanced text processing use cases, filling in a number of gaps in Swift's text support compared to other programming languages.

This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths. Like the offsetof macro in C, MemoryLayout.offset(of:) returns the distance in bytes between a pointer to a value and a pointer to one of its fields.

This proposal changes the current Package.swift manifest API for declaring for Swift language versions from freeform Integer array to a new SwiftVersion enum array.

This proposal introduces a new type of target "system library target", which moves the current system-module packages feature from package to target level.

It is common to want to confirm that every element of a sequence equals a value, or matches certain criteria. Many implementations of this can be found in use on GitHub. This proposal adds such a method to Sequence.

This proposal introduces a new Hasher type representing the standard library's universal hash function, and it extends the Hashable protocol with a new hash(into:) requirement that expresses hashing in terms of Hasher. This new requirement is intended to replace the old hashValue property, which is deprecated.

We propose to extend the toplevel withUnsafePointer(to:_:) and withUnsafeBytes(of:_:) functions to work with read-only values.

The standard library should include methods for finding the last element in a sequence, and the index of the last element in a collection, that match a given predicate.

This proposal's main focus is to create a unified random API, and a secure random API for all platforms.

This proposal adds a new API in PackageDescription to support declaring dependency on a package using its path on disk instead of the git URL.

Like many computer languages, Swift uses an escape character () to create a special interpretation of subsequent characters within a string literal. Escape character sequences represent a set of predefined, non-printing characters as well as string delimiters (the double quote), the escape character (the backslash itself), and (uniquely in Swift) to allow in-string expression interpolation.

I propose adding a mutating func toggle to Bool. It toggles the Bool.

The standard library currently includes API which allows a type to customize its description in Xcode playgrounds and Swift Playgrounds. This API takes the form of the PlaygroundQuickLook enum which enumerates types which are supported for quick looks, and the CustomPlaygroundQuickLookable protocol which allows a type to return a custom PlaygroundQuickLook value for an instance.

It is common to want to remove all occurrences of a certain element from a collection. This proposal is to add a removeAll algorithm to the standard library, which will remove all entries in a collection in-place matching a given predicate.

This proposal introduces #warning and #error directives that will cause the Swift compiler to emit a custom warning or an error during compilation.

This proposal introduces a new @dynamicMemberLookup attribute. Types that use it provide "dot" syntax for arbitrary names which are resolved at runtime - in a completely type safe way. This provides syntactic sugar that allows the user to write:

We propose introducing a pair of new attributes, @inlinable and @usableFromInline. The @inlinable attribute exports the body of a function as part of a module's interface, making it available to the optimizer when referenced from other modules. The @usableFromInline attribute marks an internal declaration as being part of the binary interface of a module, allowing it to be used from @inlinable code without exposing it as part of the module's source interface.

Currently, adding a new case to an enum is a source-breaking change, something that's at odds with Apple's established process for evolving APIs. This proposal aims to distinguish between enums that are frozen (meaning they will never get any new cases) and those that are non-frozen, and to ensure that clients handle any future cases when dealing with the latter.

Eliminate the associated type IndexDistance from Collection, and modify all uses to the concrete type Int instead.

This proposal introduces a platform condition to differentiate device and simulator builds. This condition subsumes a common pattern of conditional compilation for Metal, Keychain, and AVFoundation Camera code.

Adding a property to a public struct in Swift ought to not be a source-breaking change. However, a client in another target can currently extend a struct with a new initializer that directly initializes the struct's fields. This proposal forbids that, requiring any cross-target initializers to use self.init(…) or assign to self instead. This matches an existing restriction for classes, where cross-module initializers must be convenience initializers.

Key-path expressions can now include subscripts to reference individual positions in collections and other subscriptable types, but only when the subscript parameters are Hashable. To provide maximum utility, the standard library index types should all have Hashable conformance added.

We propose to deprecate the controversial version of a Sequence.flatMap method and provide the same functionality under a different, and potentially more descriptive, name.

This proposal removes support for the keywords weak and unowned for property declarations in a protocol.

Developers have to write large amounts of boilerplate code to support equatability and hashability of complex types. This proposal offers a way for the compiler to automatically synthesize conformance to Equatable and Hashable to reduce this boilerplate, in a subset of scenarios where generating the correct implementation is known to be possible.

This document is a spin-off from a much larger original proposal, which covers only those aspects of SE-0184 which do not deal with partial buffer memory state. Designing the partial buffer memory state API clearly requires more work, and has been left out of the scope of this document.

This proposal modifies a small number of methods in the standard library that are commonly used with the Substring type:

This proposal is a refinement of SE-0168 which introduces the ability to escape newlines in single and multi-line strings to improve readability and maintenance of source material containing excessively long lines.

This proposal adds support for declaring the language standard for C and C++ targets in a SwiftPM package.

Today String shares an Index type with its CharacterView but not with its UTF8View, UTF16View, or UnicodeScalarView. This proposal redefines String.UTF8View.Index, String.UTF16View.Index, and String.CharacterView.Index as typealiases for String.Index, and exposes a public encodedOffset property and initializer that can be used to serialize and deserialize positions in a String or Substring.

The proposal introduces a new swift run command to build and run an executable defined in the current package.

This proposal adds a unicodeScalars view to Character, similar to that on String.

In Swift 3, it is possible to modify a variable while it's being used or modified by another part of the program. This can lead to unexpected and confusing results. It also forces a great deal of conservatism onto the implementation of the compiler and the standard libraries, which must generally ensure the basic soundness of the program (no crashes or undefined behavior) even in unusual circumstances.

This proposal makes the package manager's dependency resolution behavior clearer and more intuitive. It removes the pinning commands (swift package pin & swift package unpin), replaces the swift package fetch command with a new swift package resolve command with improved behavior, and replaces the optional Package.pins file with a Package.resolved file which is always created during dependency resolution.

This proposal implements the filter operation on RangeReplaceableCollection to return the same type as the filtered collection.

As part of the introduction of the Law of Exclusivity, the current swap(_:_:) function must be addressed, as this most common uses of swap directly violate the law. This proposal introduces an alternative: a method on MutableCollection that takes two indices for swapping two elements in the same collection.

This proposal introduces the concept of a "one-sided" range, created via prefix/postfix versions of the existing range operators.

A new variant of reduce should be added to the standard library. Instead of taking a combine function that is of type (A, Iterator.Element) -> A, the full type and implementation of the added reduce will be:

NSNumber has been a strange duck in the Swift world especially when it has come to bridging and interacting with other protocols. An attempt was made to make a type preserving NSNumber subclass; however that defeated numerous optimizations in Foundation and also caused some rather unfortunate disparity between where and how the NSNumbers were created.

In Swift 3, a declaration marked private may be accessed by anything nested in the scope of the private declaration. For example, a private property or method defined on a struct may be accessed by other methods defined within that struct.

This proposal introduces multi-line string literals to Swift source code. This has been discussed a few times on swift-evolution most recently putting forward a number of different syntaxes that could achieve this goal each of which has their own use case and constituency for discussion.

As part of the proposal for a Swift archival and serialization API (SE-0166), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new Codable types in NSKeyedArchiver and NSKeyedUnarchiver.

Foundation's current archival and serialization APIs (NSCoding, NSJSONSerialization, NSPropertyListSerialization, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.

This proposal comprises a variety of commonly (and less commonly) suggested improvements to the standard library's Dictionary type, from merging initializers to dictionary-specific filter and mapValues methods. The proposed additions to Dictionary, and the corresponding changes to Set, are detailed in the sections below.

This proposal disallows the final keyword when declaring functions in protocol extensions.

This proposal is to implement a subset of the changes from the Swift 4 String Manifesto.

This proposal enhances the Package.swift manifest APIs to support custom target layouts, and removes a convention which allowed omission of targets from the manifest.

We propose a family of concrete Key Path types that represent uninvoked references to properties that can be composed to form paths through many values and directly get/set their underlying values.

One can explicitly write @objc on any Swift declaration that can be expressed in Objective-C. As a convenience, Swift also infers @objc in a number of places to improve interoperability with Objective-C and eliminate boilerplate. This proposal scales back the inference of @objc to only those cases where the declaration must be available to Objective-C to maintain semantic coherence of the model, e.g., when overriding an @objc method or implementing a requirement of an @objc protocol. Other cases currently supported (e.g., a method declared in a subclass of NSObject) would no longer infer @objc, but one could continue to write it explicitly to produce Objective-C entry points.

This is a proposal for redesigning the Package.swift manifest APIs provided by Swift Package Manager. This proposal only redesigns the existing public APIs and does not add any new functionality; any API to be added for new functionality will happen in separate proposals.

This proposal lifts restrictions on associated types in protocols. Their constraints will be allowed to reference any protocol, including protocols that depend on the enclosing one (recursive constraints).

This proposal brings more expressive power to the type system by allowing Swift to represent existentials of classes and subtypes which conform to protocols.

In Swift 3, associated values of an enum case are represented by a tuple. This implementation causes inconsistencies in case declaration, construction and pattern matching in several places.

This proposal addresses significant unexpected performance gaps when using dictionaries. It introduces type-specific collections for a Dictionary instance's keys and values properties.

This proposal introduces a "Swift tools version" which is declared for each Swift package. The tools version declares the minimum version of the Swift tools required to use the package, determines what version of the PackageDescription API should be used in the Package.swift manifest, and determines which Swift language compatibility version should be used to parse the Package.swift manifest.

This proposal adds support for the Swift compiler's new "language compatibility version" feature to the package manager.

This proposal adds enhancements to the package manifest to support development of packages without strict versioning. This is one of two features, along with "Package Manager Support for Top of Tree development", being proposed to enable use of SwiftPM to develop on "top of tree" of related packages.

This proposal adds enhancements to swift package edit to support development of packages without strict versioning ("top of tree" development).

Make it possible to have generic subscripts. Example:

The version of UnsafeMutablePointer.initialize(from:) that takes a Collection should be deprecated in favor of a new method on UnsafeMutableBufferPointer that takes a Sequence, with a goal of improving memory safety and enabling faster initialization of memory from sequences. Similarly, UnsafeMutableRawPointer.initializeMemory(as:from:) should be deprecated in favor of a new UnsafeMutableRawBufferPointer.initialize(as:from:).

This proposal introduces the concept of products to the Swift Package Manager, and proposes enhancements to the Package.swift syntax to let packages define products that can be referenced by other packages.

This is a proposal for adding package manager features to "pin" or "lock" package dependencies to particular versions.

Conditional conformances express the notion that a generic type will conform to a particular protocol only when its type arguments meet certain requirements. For example, the Array collection can implement the Equatable protocol only when its elements are themselves Equatable, which can be expressed via the following conditional conformance on Equatable:

This proposal seeks to introduce a where clause to associated type declarations and improvements to protocol constraints to bring associated types the same expressive power as generic type parameters.

Swift's existing @available(...) attribute indicates the lifecycle of a given declaration, either unconditionally or relative to a particular platform or OS version range.

Optionals can be used as values of Any type. After SE-0116, this means you can pass an Optional to an Objective-C method expecting nonnull id:

A handful of Swift numeric types are bridged to NSNumber when passed into Objective-C object contexts. We should extend this bridging behavior to all Swift numeric types. We should also bridge common Cocoa structs such as NSRange by boxing them into NSValue objects.

This is a purely additive proposal to improve the Swift 3 migration experience.

We propose to deprecate or move protocols that shouldn't be a part of the standard library's public API going forward.

This proposal is to introduce, as a bugfix, a replacement for sizeofValue(_:) and related functions.

As new, source-incompatible versions of Swift come into use, there is a growing need for packages to be authored in a way that makes them usable from multiple versions of Swift. While package authors want to adopt new Swift versions as soon as possible, they also need to support their existing clients.

This proposal removes nulTerminatedUTF8 and renames nulTerminatedUTF8CString to enhance clarity and reduce mismatch between user expectations and the Swift programming language.

Swift currently defines two similar functions, joined(separator:) and flatten(). joined(separator:) has a specialized implementation for Strings, and flatten() has implementations for various kinds of collections.

We propose to add a type-erased AnyHashable container to the standard library.

This proposal suggest replacing String initializers taking Character or UnicodeScalar as a repeating value by a more general initializer that takes a String as a repeating value. This is done to avoid the ambiguities in the current String API, which can be only resolved by explicit casting. It is also proposed to remove one of the String.append APIs to match these changes.

The Swift Package Manager uses a convention-based rather than a declarative approach for various aspects of package configuration. This is as true of the naming and structure of tests as of other kinds of targets.

This proposal aims to change some UnicodeScalar initializers (ones that are non-failable) from non-failable to failable. i.e., in case a UnicodeScalar can not be constructed, nil is returned.

This proposal deals with three routines and one class related to pointers and buffers. The goal of this proposal is to update the API to match new API guidelines and remove redundant identifiers.

Remove NonObjectiveCBase and isUniquelyReferenced(_ object: T). isUniquelyReferenced can be replaced by isUniquelyReferencedNonObjC(_ object: T). This replacement is as performant as the call to isUniquelyReferenced in cases where the compiler has static knowledge that the type of object is a native Swift class and dynamically has the same semantics for native swift classes. This change will remove surface API. Rename isUniquelyReferencedNonObjC to isKnownUniquelyReferenced and no longer promise to return false for @objc class instances. Cleanup the ManagedBufferPointer API by renaming holdsUniqueReference to isUniqueReference and removing holdsUniqueOrPinnedReference.

Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a 'bitPattern:’ label to make it clear at the use site that we interpret the value as a bit pattern.

Swift's Comparable protocol requires 4 operators, <, <=, >, and >=, beyond the requirements of Equatable.

This proposal revises the signature for the collection partition algorithm. Partitioning is a foundational API for sorting and for searching through sorted collections.

We propose a revision to the names and argument labels of closure parameters in standard library APIs.

Since the first release of Swift, marking a class public has provided two capabilities: it allows other modules to instantiate and use the class, and it also allows other modules to define subclasses of it. Similarly, marking a class member (a method, property, or subscript) public has provided two capabilities: it allows other modules to use the member, and it also allows those modules to override it.

Objective-C interfaces that use id and untyped collections should be imported into Swift as taking the Any type instead of AnyObject.

This proposal renames the LiteralConvertible protocols to ExpressibleByLiteral.

This proposal updates parameters and generic type parameters from value names to header names for ManagedBuffer, ManagedProtoBuffer, and ManagedBufferPointer.

The standard library lacks equivalents to the floor() and ceil() functions found in the standard libraries of most other languages. Currently, we need to import Darwin or Glibc in order to access the C standard library versions.

Swift's error handling model interoperates directly with Cocoa's NSError conventions. For example, an Objective-C method with an NSError parameter, e.g.,

Swift's type system should not allow function argument labels to be expressed as part of a function type.

Swift's type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments.

For legacy and historical reasons Swift has supported a protocol named Boolean for abstracting over different concrete Boolean types. This causes problems primarily because it is pointless and very confusing to newcomers to Swift: is quite different than Bool, but shows up right next to it in documentation and code completion. Once you know that it is something you don't want, you constantly ignore it. Boolean values are simple enough that we don't need a protocol to abstract over multiple concrete implementations.

Swift enforces type safe access to memory and follows strict aliasing rules. However, code that uses unsafe APIs or imported types can circumvent the language's natural type safety. Consider the following example of type punning using the UnsafePointer type: