Before you initiate a pull request, please read the process document. Ideas should be thoroughly discussed on the swift-evolution mailing list first.
This repository tracks the ongoing evolution of Swift. It contains:
- Goals for upcoming Swift releases (this document).
- The Swift evolution review schedule tracking proposals to change Swift.
- The Swift evolution process that governs the evolution of Swift.
- Commonly Rejected Changes, proposals which have been denied in the past.
This document describes goals for the Swift language on a per-release basis, usually listing minor releases adding to the currently shipping version and one major release out. Each release will have many smaller features or changes independent of these larger goals, and not all goals are reached for each release.
Goals for past versions are included at the bottom of the document for historical purposes, but are not necessarily indicative of the features shipped. The release notes for each shipped version are the definitive list of notable changes in each release.
Expected release date: Late 2016
The primary goal of this release is to stabilize the binary interface of the language and standard library. As part of this process, we will focus and refine the language to provide better overall consistency in feel and implementation. Swift 3.0 will contain source-breaking changes from Swift 2.x where necessary to support these goals. More concretely, this release is focused on several key areas:
- Stable ABI: Stabilize the binary interface (ABI) to guarantee a level of binary compatibility moving forward. This involves finalizing runtime data structures, name mangling, calling conventions, and so on, as well as finalizing some of the details of the language itself that have an impact on its ABI. Stabilizing the ABI also extends to the Standard Library, its data types, and core algorithms. Successful ABI stabilization means that applications and libraries compiled with future versions of Swift can interact at a binary level with applications and libraries compiled with Swift 3.0, even if the source language changes.
- Resilience: Solve the general problem of fragile binary interface, which currently requires that an application be recompiled if any of the libraries it depends on changes. For example, adding a new stored property or overridable method to a class should not require all subclasses of that class to be recompiled. There are several broad concerns for resilience:
- What changes are resilient?: Define the kinds of changes that can be made to a library without breaking clients of that library. Source-compatible changes to libraries are good candidates for resilient changes, but such decisions also consider the effects on the implementation.
- How is a resilient library implemented?: What runtime representations are necessary to allow applications to continue to work after making resilient changes to a library? This dovetails with the stabilization of the ABI, because the stable ABI should be a resilient ABI.
- How do we maintain high performance?: Resilient implementations often incur more execution overhead than non-resilient (or fragile) implementations, because resilient implementations need to leave some details unspecified until load time, such as the specific sizes of a class or offsets of a stored property.
- Portability: Make Swift available on other platforms and ensure that one can write portable Swift code that works properly on all of those platforms.
- Type system cleanup and documentation: Revisit and document the various subtyping and conversion rules in the type system, as well as their implementation in the compiler's type checker. The intent is to converge on a smaller, simpler type system that is more rigorously defined and more faithfully represented by the type checker.
- Complete generics: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of
Equatableelements isEquatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI. - Focus and refine the language: Despite being a relatively young language, Swift's rapid development has meant that it has accumulated some language features and library APIs that don't fit well with the language as a whole. Swift 3 will remove or improve those features to provide better overall consistency for Swift.
- API design guidelines: The way in which Swift is used in popular libraries has almost as much of an effect on the character of Swift code as the Swift language itself. The API design guidelines provide guidance for building great Swift APIs. For Swift 3.0, the Swift standard library and core libraries are being updated to match these guidelines, and Swift's Objective-C importer will automatically map from the Cocoa guidelines for Objective-C to the Swift API guidelines.
A significant part of delivering a major release is in deciding what not to do, which means deferring many good ideas. The following is a sampling of potentially good ideas that are not in scope for Swift 3.0:
-
Full source compatibility: Swift 3.0 will not provide full source compatibility. Rather, it can and will introduce source-breaking changes needed to support the main goals of Swift 3.0.
-
Concurrency: Swift 3.0 relies entirely on platform concurrency primitives (libdispatch, Foundation, pthreads, etc.) for concurrency. Language support for concurrency is an often-requested and potentially high-value feature, but is too large to be in scope for Swift 3.0.
-
C++ Interoperability: Swift's interoperability with C and Objective-C is one of its major strengths, allowing it to integrate with platform APIs. Interoperability with C++ libraries would enhance Swift's ability to work with existing libraries and APIs. However, C++ itself is a very complex language, and providing good interoperability with C++ is a significant undertaking that is out of scope for Swift 3.0.
-
Hygienic Macros and Compile-Time Evaluation: A first-class macro system, or support for compile-time code execution in general, is something we may consider in future releases. We don't want the existence of a macro system to be a workaround that reduces the incentive for making the core language great.
-
Implicit conversions between numeric types: We may do this in a future release, but there is simply too much work to be done first. Before we can loosen these type rules, we will need to speed up the type checker, redesign the numerics protocols, and implement a subtyping feature to express the permitted conversions. This won't all come together before Swift 3.0 ships.
-
Major new library functionality: The Swift Standard Library is focused on providing core "language" functionality as well as common data structures. The "corelibs" projects are focused on providing existing Foundation functionality in a portable way. We will consider minor extensions to their existing feature sets to round out these projects.
On the other hand, major new libraries (e.g. a new Logging subsystem) are best developed as independent projects on GitHub (or elsewhere) and organized with the Swift Package Manager. Beyond Swift 3 we may consider standardizing popular packages or expanding the scope of the project.
- SE-0002: Removing currying
funcdeclaration syntax - SE-0003: Removing
varfrom Function Parameters - SE-0004: Remove the
++and--operators - SE-0005: Better Translation of Objective-C APIs Into Swift
- SE-0006: Apply API Guidelines to the Standard Library
- SE-0007: Remove C-style for-loops with conditions and incrementers
- SE-0016: Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer
- SE-0019: Swift Testing
- SE-0023: API Design Guidelines
- SE-0028: Modernizing Swift's Debugging Identifiers (_FILE_, etc)
- SE-0029: Remove implicit tuple splat behavior from function applications
- SE-0031: Adjusting inout Declarations for Type Decoration
- SE-0034: Disambiguating Line Control Statements from Debugging Identifiers
- SE-0037: Clarify interaction between comments & operators
- SE-0039: Modernizing Playground Literals
- SE-0040: Replacing Equal Signs with Colons For Attribute Arguments
- SE-0043: Declare variables in 'case' labels with multiple patterns
- SE-0046: Establish consistent label behavior across all parameters including first labels
- SE-0049: Move @noescape and @autoclosure to be type attributes
- SE-0053: Remove explicit use of
letfrom Function Parameters - SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly
- SE-0055: Make unsafe pointer nullability explicit using Optional
- SE-0061: Add Generic Result and Error Handling to autoreleasepool()
- SE-0065: A New Model For Collections and Indices
- SE-0069: Mutability and Foundation Value Types
- SE-0071: Allow (most) keywords in member references
This is the list of proposals which have been accepted for inclusion into Swift, but they are not implemented yet, and may not have anyone signed up to implement them. If they are not implemented in time for Swift 3, they will roll into a subsequent release.
- SE-0008: Add a Lazy flatMap for Sequences of Optionals
- SE-0017: Change
Unmanagedto useUnsafePointer - SE-0025: Scoped Access Level
- SE-0032: Add
findmethod toSequenceType - SE-0033: Import Objective-C Constants as Swift Types
- SE-0035: Limiting
inoutcapture to@noescapecontexts - SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations
- SE-0038: Package Manager C Language Target Support
- SE-0042: Flattening the function type of unapplied method references
- SE-0044: Import as Member
- SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib
- SE-0047: Defaulting non-Void functions so they warn on unused results
- SE-0048: Generic Type Aliases
- SE-0052: Change IteratorType post-nil guarantee
- SE-0054: Abolish
ImplicitlyUnwrappedOptionaltype - SE-0057: Importing Objective-C Lightweight Generics
- SE-0062: Referencing Objective-C key-paths
- SE-0063: SwiftPM System Module Search Paths
- SE-0064: Referencing the Objective-C selector of property getters and setters
- SE-0066: Standardize function type argument syntax to require parentheses
- SE-0067: Enhanced Floating Point Protocols
- SE-0068: Expanding Swift
Selfto class members and value types - SE-0070: Make Optional Requirements Objective-C-only
- SE-0072: Fully eliminate implicit bridging conversions from Swift
This release focused on fixing bugs, improving quality-of-implementation (QoI) with better warnings and diagnostics, improving compile times, and improving performance. It put some finishing touches on features introduced in Swift 2.0, and included some small additive features that don't break Swift code or fundamentally change the way Swift is used. As a step toward Swift 3, it introduced warnings about upcoming source-incompatible changes in Swift 3 so that users can begin migrating their code sooner.
Aside from warnings, a major goal of this release was to be as source compatible as practical with Swift 2.0.
- SE-0001: Allow (most) keywords as argument labels
- SE-0011: Replace
typealiaskeyword withassociatedtypefor associated type declarations - SE-0014: Constraining
AnySequence.init - SE-0015: Tuple comparison operators
- SE-0020: Swift Language Version Build Configuration
- SE-0021: Naming Functions with Argument Labels
- SE-0022: Referencing the Objective-C selector of a method
- SE-0009: Require self for accessing instance members
- SE-0010: Add StaticString.UnicodeScalarView
- SE-0013: Remove Partial Application of Non-Final Super Methods (Swift 2.2)
- SE-0024: Optional Value Setter
??= - SE-0027: Expose code unit initializers on String
- SE-0056: Allow trailing closures in
guardconditions