## Motivation
@@ -352,7 +352,7 @@ That is, a `public` class could be used as a compositional superclass,
useful for adding new storage to an existing identity but not for
messing with its invariants. This would prevent the creation of
sealed hierarchies and is inconsistent with the general principle
-that restrictons on future evolution should be opt-in. Authors would
+that restrictions on future evolution should be opt-in. Authors would
have no ability to reserve the right to decide later whether to
allow subclasses; declaring something `final` is irrevocable. This
could be added in a future extension, but it is not the right rule
@@ -396,7 +396,7 @@ We may want to reconsider the need for `final` in the light of this change.
## Impact on existing code
This would be a backwards-breaking change for all classes and methods that are
-public and non-final, which code outside of their module has overriden.
+public and non-final, which code outside of their module has overridden.
Those classes/methods would fail to compile. Their superclass would need to be
changed to `open`.
diff --git a/proposals/0118-closure-parameter-names-and-labels.md b/proposals/0118-closure-parameter-names-and-labels.md
index 39fff01a3f..2f89190564 100644
--- a/proposals/0118-closure-parameter-names-and-labels.md
+++ b/proposals/0118-closure-parameter-names-and-labels.md
@@ -2,14 +2,14 @@
* Proposal: [SE-0118](0118-closure-parameter-names-and-labels.md)
* Authors: [Dave Abrahams](https://github.com/dabrahams), [Dmitri Gribenko](https://github.com/gribozavr), [Maxim Moiseev](https://github.com/moiseev)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000230.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0118-closure-parameter-names-and-labels/3387)
* Bug: [SR-2072](https://bugs.swift.org/browse/SR-2072)
## Revision History
-- [v1](https://github.com/apple/swift-evolution/blob/ae4a55ab217cc9755004cbf2b29db24e28645d15/proposals/0118-closure-parameter-names-and-labels.md) (as proposed)
+- [v1](https://github.com/swiftlang/swift-evolution/blob/ae4a55ab217cc9755004cbf2b29db24e28645d15/proposals/0118-closure-parameter-names-and-labels.md) (as proposed)
- v2: fixed spelling of identifiers containing `Utf8` to read `UTF8` per convention.
## Introduction
@@ -18,10 +18,10 @@ We propose a revision to the names and argument labels of closure
parameters in standard library APIs.
Swift-evolution thread:
-[Take 2: Stdlib closure argument labels and parameter names](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022612.html)
+[Take 2: Stdlib closure argument labels and parameter names](https://forums.swift.org/t/take-2-stdlib-closure-argument-labels-and-parameter-names/3180)
Discussion of earlier revision of the proposal:
-[Stdlib closure argument labels and parameter names](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021470.html)
+[Stdlib closure argument labels and parameter names](https://forums.swift.org/t/stdlib-closure-argument-labels-and-parameter-names/3046)
## Motivation
diff --git a/proposals/0119-extensions-access-modifiers.md b/proposals/0119-extensions-access-modifiers.md
index 75f1a4f3b1..9112147c9a 100644
--- a/proposals/0119-extensions-access-modifiers.md
+++ b/proposals/0119-extensions-access-modifiers.md
@@ -2,21 +2,21 @@
* Proposal: [SE-0119](0119-extensions-access-modifiers.md)
* Author: [Adrian Zubarev](https://github.com/DevAndArtist)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000250.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0119-remove-access-modifiers-from-extensions/3493)
## Introduction
-One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.
+One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.
-Swift-evolution thread: [\[Proposal\] Revising access modifiers on extensions](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/022144.html)
+Swift-evolution thread: [\[Proposal\] Revising access modifiers on extensions](https://forums.swift.org/t/proposal-revising-access-modifiers-on-extensions/3138)
## Motivation
-The access control of classes, enums and structs in Swift is very easy to learn and memorize. It also disallows to suppress the access modifier of implemented conformance members to lower access modifier if the host type has an access modifier of higher or equal level.
+The access control of classes, enums and structs in Swift is very easy to learn and memorize. It also disallows to suppress the access modifier of implemented conformance members to lower access modifier if the host type has an access modifier of higher or equal level.
-`public` > `internal` > `fileprivate` >= `private`
+`public` > `internal` > `fileprivate` >= `private`
```swift
public class A {
@@ -56,7 +56,7 @@ This simple access control model also allows us to nest types inside each other
*Extensions* however behave differently when it comes to their access control:
-* The *access modifier* of an *extension* sets the default modifier of its members which do not have their own localy defined modifier.
+* The *access modifier* of an *extension* sets the default modifier of its members which do not have their own locally defined modifier.
```swift
public struct D {}
@@ -150,7 +150,7 @@ I propose to revise the access control on extensions by removing access modifier
> That way, access for members follows the same defaults as in the original type.
>
-> [Jordan Rose](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022341.html)
+> [Jordan Rose](https://forums.swift.org/t/proposal-revising-access-modifiers-on-extensions/3138/15)
* It would be possible to conform types to a protocol using an *extension* which has an explicit *access modifier*. The *access modifier* respects the modifier of the extended type and the protocol to which it should be conformed.
@@ -234,7 +234,7 @@ I propose to revise the access control on extensions by removing access modifier
fileprivate group {
- // Every group memebr is `fileprivate`
+ // Every group member is `fileprivate`
func member1() {}
func member2() {}
func member3() {}
@@ -243,7 +243,7 @@ I propose to revise the access control on extensions by removing access modifier
}
}
```
- Such a mechanism could also be used outside extensions! This idea has its own discussion [thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022644.html).
+ Such a mechanism could also be used outside extensions! This idea has its own discussion [thread](https://forums.swift.org/t/post-swift-3-proposal-introducing-group-mechanism/3196).
## Proposed solution
@@ -286,7 +286,7 @@ Iff the *access-level-modifier* is not present, the access modifier on extension
```diff
- extension SomeType : SomeProtocol {
+ public extension SomeType : SomeProtocol {
- public func someMemeber()
+ public func someMember()
}
```
diff --git a/proposals/0120-revise-partition-method.md b/proposals/0120-revise-partition-method.md
index 223d4ecb92..a222aaaa45 100644
--- a/proposals/0120-revise-partition-method.md
+++ b/proposals/0120-revise-partition-method.md
@@ -2,17 +2,17 @@
* Proposal: [SE-0120](0120-revise-partition-method.md)
* Authors: [Lorenzo Racca](https://github.com/lorenzoracca), [Jeff Hajewski](https://github.com/j-haj), [Nate Cook](https://github.com/natecook1000)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000242.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0120-revise-partition-method-signature/3475)
* Bug: [SR-1965](https://bugs.swift.org/browse/SR-1965)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/1dcfd35856a6f9c86af2cf7c94a9ab76411739e3/proposals/0120-revise-partition-method.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/1dcfd35856a6f9c86af2cf7c94a9ab76411739e3/proposals/0120-revise-partition-method.md)
## Introduction
This proposal revises the signature for the collection partition algorithm. Partitioning is a foundational API for sorting and for searching through sorted collections.
-- Swift-evolution thread: [Feedback from standard library team](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016729.html)
+- Swift-evolution thread: [Feedback from standard library team](https://forums.swift.org/t/review-se-0074-implementation-of-binary-search-functions/2438/5)
- Swift Bug: [SR-1965](https://bugs.swift.org/browse/SR-1965)
## Motivation
diff --git a/proposals/0121-remove-optional-comparison-operators.md b/proposals/0121-remove-optional-comparison-operators.md
index 5a8b90fee4..45073740df 100644
--- a/proposals/0121-remove-optional-comparison-operators.md
+++ b/proposals/0121-remove-optional-comparison-operators.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0121](0121-remove-optional-comparison-operators.md)
* Author: [Jacob Bandes-Storch](https://github.com/jtbandes)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000245.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0121-remove-optional-comparison-operators/3478)
* Implementation: [apple/swift#3637](https://github.com/apple/swift/pull/3637)
## Introduction
@@ -23,9 +23,9 @@ public func >= (lhs: T?, rhs: T?) -> Bool
This proposal removes the above 4 functions.
swift-evolution discussion threads:
-- [Optional comparison operators](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024121.html)
-- [Possible bug with arithmetic optional comparison ?](https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160523/002095.html)
-- [? suffix for <, >, <=, >= comparisons with optionals to prevent subtle bugs](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001264.html)
+- [Optional comparison operators](https://forums.swift.org/t/optional-comparison-operators/3320)
+- [Possible bug with arithmetic optional comparison ?](https://forums.swift.org/t/possible-bug-with-arithmetic-optional-comparison/2749)
+- [? suffix for <, >, <=, >= comparisons with optionals to prevent subtle bugs](https://forums.swift.org/t/suffix-for-comparisons-with-optionals-to-prevent-subtle-bugs/350)
## Motivation
@@ -47,7 +47,7 @@ a < b // b is coerced from "Int" to "Int?" to match the parameter type.
[SE-0123](0123-disallow-value-to-optional-coercion-in-operator-arguments.md) seeks to remove this coercion (for arguments to operators) for a variety of reasons.
-If the coercion is not removed (if no change is made), the results of comparisons with Optional values are sometimes **surprising**, making it easy to write bugs. In a thread from December 2015, [Al Skipp offers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001267.html) the following example:
+If the coercion is not removed (if no change is made), the results of comparisons with Optional values are sometimes **surprising**, making it easy to write bugs. In a thread from December 2015, [Al Skipp offers](https://forums.swift.org/t/suffix-for-comparisons-with-optionals-to-prevent-subtle-bugs/350/3) the following example:
```swift
struct Pet {
diff --git a/proposals/0122-use-colons-for-subscript-type-declarations.md b/proposals/0122-use-colons-for-subscript-type-declarations.md
index 321d8be2db..cfabbd5dbd 100644
--- a/proposals/0122-use-colons-for-subscript-type-declarations.md
+++ b/proposals/0122-use-colons-for-subscript-type-declarations.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0122](0122-use-colons-for-subscript-type-declarations.md)
* Author: [James Froggatt](https://github.com/MutatingFunk)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000258.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0122-use-colons-for-subscript-declarations/3545)
## Introduction
@@ -19,7 +19,7 @@ subscript(externalName internalName: ParamType) -> ElementType {
The initial keyword `subscript` is followed by a parameter list, followed by an arrow to the accessed type. This proposal is to replace the arrow with a colon, to match accessor declarations elsewhere in the language.
-Swift-evolution thread: [Discussion thread topic for that proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023883.html)
+Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/change-subscripts-to-use-colons/3346)
## Motivation
diff --git a/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md b/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md
index 0d27ca6a9e..29ecfb3225 100644
--- a/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md
+++ b/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0123](0123-disallow-value-to-optional-coercion-in-operator-arguments.md)
* Authors: [Mark Lacey](https://github.com/rudkx), [Doug Gregor](https://github.com/DougGregor), [Jacob Bandes-Storch](https://github.com/jtbandes)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000246.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0123-disallow-coercion-to-optionals-in-operator-arguments/3479)
## Introduction
@@ -46,7 +46,7 @@ This coercion happens for normal function calls, the assignment
statement, and for operators defined with optional parameter types,
e.g. the comparison operators and the nil-coalescing operator (`??`).
-Swift-evolution thread: [Optional comparison operators](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024121.html)
+Swift-evolution thread: [Optional comparison operators](https://forums.swift.org/t/optional-comparison-operators/3320)
## Proposal
diff --git a/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md b/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md
index 56b80bca4c..892a806a96 100644
--- a/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md
+++ b/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0124](0124-bitpattern-label-for-int-initializer-objectidentfier.md)
* Author: [Arnold Schwaighofer](https://github.com/aschwaighofer)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000241.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0124-int-init-objectidentifier-and-uint-init-objectidentifier-should-have-a-bitpattern-label/3474)
* Bug: [SR-2064](https://bugs.swift.org/browse/SR-2064)
## Introduction
@@ -19,7 +19,7 @@ as a bit pattern.
}
```
-- Swift-evolution thread: [Pitch](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024323.html)
+- Swift-evolution thread: [Pitch](https://forums.swift.org/t/pitch-int-init-objectidentifier-and-uint-init-objectidentifier-should-have-a-bitpattern-label/3384)
- Swift Bug: [SR-2064](https://bugs.swift.org/browse/SR-2064)
- Branch with change to stdlib: [int_init_objectidentifier_label] (https://github.com/aschwaighofer/swift/tree/int_init_objectidentifier_label)
diff --git a/proposals/0125-remove-nonobjectivecbase.md b/proposals/0125-remove-nonobjectivecbase.md
index 57e14871fa..d9b887fed1 100644
--- a/proposals/0125-remove-nonobjectivecbase.md
+++ b/proposals/0125-remove-nonobjectivecbase.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0125](0125-remove-nonobjectivecbase.md)
* Author: [Arnold Schwaighofer](https://github.com/aschwaighofer)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000261.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0125-remove-nonobjectivecbase-and-isuniquelyreferenced/3548)
* Bug: [SR-1962](http://bugs.swift.org/browse/SR-1962)
## Introduction
@@ -15,14 +15,14 @@ Remove `NonObjectiveCBase` and
`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 dyamically has the same semantics for native swift classes.
+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`.
-- Swift-evolution thread: [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024806.html)
+- Swift-evolution thread: [Review](https://forums.swift.org/t/review-se-0125-remove-nonobjectivecbase-and-isuniquelyreferenced/3462)
- Branch with change to stdlib: [remove_nonobjectivecbase_2]
(https://github.com/aschwaighofer/swift/commits/remove_nonobjectivecbase_2)
diff --git a/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md b/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md
index a32284d1fd..6901aa0b6e 100644
--- a/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md
+++ b/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0126](0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md)
* Authors: [Adrian Zubarev](https://github.com/DevAndArtist), [Anton Zhilin](https://github.com/Anton3)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Withdrawn**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000251.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/withdrawn-for-revision-se-0126-refactor-metatypes-repurpose-t-self-and-mirror/3499)
## Introduction
@@ -12,9 +12,9 @@ This proposal wants to revise metatypes `T.Type`, repurpose *public* `T.self` no
Swift-evolution threads:
-* [\[Proposal\] Refactor Metatypes, repurpose T[dot]self and Mirror](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024772.html)
-* [\[Discussion\] Seal `T.Type` into `Type`](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023818.html)
-* [\[Discussion\] Can we make `.Type` Hashable?](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023067.html)
+* [\[Proposal\] Refactor Metatypes, repurpose T[dot]self and Mirror](https://forums.swift.org/t/proposal-refactor-metatypes-repurpose-t-dot-self-and-mirror/3460)
+* [\[Discussion\] Seal `T.Type` into `Type`](https://forums.swift.org/t/discussion-seal-t-type-into-type-t/3340)
+* [\[Discussion\] Can we make `.Type` Hashable?](https://forums.swift.org/t/discussion-can-we-make-type-hashable/3232)
GitHub Gist thread:
diff --git a/proposals/0127-cleaning-up-stdlib-ptr-buffer.md b/proposals/0127-cleaning-up-stdlib-ptr-buffer.md
index 3b4a295cc4..f00bb6631a 100644
--- a/proposals/0127-cleaning-up-stdlib-ptr-buffer.md
+++ b/proposals/0127-cleaning-up-stdlib-ptr-buffer.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0127](0127-cleaning-up-stdlib-ptr-buffer.md)
* Author: [Charlie Monroe](https://github.com/charlieMonroe)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000262.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0127-cleaning-up-stdlib-pointer-and-buffer-routines/3549)
* Bugs: [SR-1937](https://bugs.swift.org/browse/SR-1937),
[SR-1955](https://bugs.swift.org/browse/SR-1955),
[SR-1957](https://bugs.swift.org/browse/SR-1957)
@@ -15,7 +15,7 @@ This proposal deals with three routines and one class related to pointers and bu
The goal of this proposal is to update the API to match new API guidelines and remove
redundant identifiers.
-Swift-evolution thread: [Cleaning up stdlib Pointer and Buffer Routines](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023518.html)
+Swift-evolution thread: [Cleaning up stdlib Pointer and Buffer Routines](https://forums.swift.org/t/discussion-cleaning-up-stdlib-pointer-and-buffer-routines-open-issues-affecting-standard-library-api-stability/3295)
## Motivation
diff --git a/proposals/0128-unicodescalar-failable-initializer.md b/proposals/0128-unicodescalar-failable-initializer.md
index dfac20a297..29e75877b8 100644
--- a/proposals/0128-unicodescalar-failable-initializer.md
+++ b/proposals/0128-unicodescalar-failable-initializer.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0128](0128-unicodescalar-failable-initializer.md)
* Author: [Xin Tong](https://github.com/trentxintong)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000259.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0128-change-failable-unicodescalar-initializers-to-failable/3546)
* Implementation: [apple/swift#3662](https://github.com/apple/swift/pull/3662)
## Introduction
diff --git a/proposals/0129-package-manager-test-naming-conventions.md b/proposals/0129-package-manager-test-naming-conventions.md
index a82e746afa..f3e218b70c 100644
--- a/proposals/0129-package-manager-test-naming-conventions.md
+++ b/proposals/0129-package-manager-test-naming-conventions.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0129](0129-package-manager-test-naming-conventions.md)
* Author: [Anders Bertelrud](https://github.com/abertelrud)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160725/000572.html)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0129-package-manager-test-naming-conventions/3574)
## Introduction
diff --git a/proposals/0130-string-initializers-cleanup.md b/proposals/0130-string-initializers-cleanup.md
index b2b3c18878..05a3e7f821 100644
--- a/proposals/0130-string-initializers-cleanup.md
+++ b/proposals/0130-string-initializers-cleanup.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0130](0130-string-initializers-cleanup.md)
* Author: Roman Levenstein
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000260.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0130-replace-repeating-character-and-unicodescalar-forms-of-string-init/3547)
## Introduction
diff --git a/proposals/0131-anyhashable.md b/proposals/0131-anyhashable.md
index 13555ffc69..aa7547d367 100644
--- a/proposals/0131-anyhashable.md
+++ b/proposals/0131-anyhashable.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0131](0131-anyhashable.md)
* Author: [Dmitri Gribenko](https://github.com/gribozavr)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000263.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0131-add-anyhashable-to-the-standard-library/3553)
## Introduction
@@ -19,7 +19,7 @@ hashable values. From SE-0116:
> hashable type that is itself `Hashable`, for use as the upper-bound
> type of heterogeneous `Dictionary`s and `Set`s.
-Swift-evolution thread: [Add AnyHashable to the standard library](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025264.html).
+Swift-evolution thread: [Add AnyHashable to the standard library](https://forums.swift.org/t/add-anyhashable-to-the-standard-library/3517).
## Motivation
diff --git a/proposals/0132-sequence-end-ops.md b/proposals/0132-sequence-end-ops.md
index 3d31167f52..a9136f73e5 100644
--- a/proposals/0132-sequence-end-ops.md
+++ b/proposals/0132-sequence-end-ops.md
@@ -1,10 +1,10 @@
# Rationalizing Sequence end-operation names
* Proposal: [SE-0132](0132-sequence-end-ops.md)
-* Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Dave Abrahams](https://github.com/dabrahams)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
+* Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Dave Abrahams](https://github.com/dabrahams)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000267.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/deferred-se-0132-rationalizing-sequence-end-operation-names/3577)
## Introduction
@@ -14,7 +14,7 @@ inconsistent naming which can make it difficult to find inverses or
remember what the standard library offers. We propose that we standardize
these names so they follow consistent, predictable patterns.
-Swift-evolution thread: [[Draft] Rationalizing Sequence end-operation names](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021872.html)
+Swift-evolution thread: [[Draft] Rationalizing Sequence end-operation names](https://forums.swift.org/t/draft-rationalizing-sequence-end-operation-names/3103)
### Scope
@@ -152,7 +152,7 @@ the direction, but do not indicate the direction in their names:
Adding a direction to these APIs would make their behavior clearer and
permit us to offer opposite-end equivalents in the future. (Unmerged
-[swift-evolution pull request 329](https://github.com/apple/swift-evolution/pull/329)
+[swift-evolution pull request 329](https://github.com/swiftlang/swift-evolution/pull/329)
would add `lastIndex` methods.)
### Operations taking an index are really slicing
diff --git a/proposals/0133-rename-flatten-to-joined.md b/proposals/0133-rename-flatten-to-joined.md
index 397fe41cc8..4408b1a775 100644
--- a/proposals/0133-rename-flatten-to-joined.md
+++ b/proposals/0133-rename-flatten-to-joined.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0133](0133-rename-flatten-to-joined.md)
* Author: [Jacob Bandes-Storch](https://github.com/jtbandes)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000265.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0133-rename-flatten-to-joined/3575)
* Implementation: [apple/swift#3809](https://github.com/apple/swift/pull/3809),
[apple/swift#3838](https://github.com/apple/swift/pull/3838),
[apple/swift#3839](https://github.com/apple/swift/pull/3839)
@@ -31,8 +31,8 @@ https://github.com/apple/swift/blob/c6e828f761fc30f7ce444431de7da52814f96595/std
https://github.com/apple/swift/blob/f72a82327b172e1a2979e46cb7a579e3cc2f3bd6/stdlib/public/core/Flatten.swift.gyb
Swift-evolution threads:
-- [[Pitch] Unify joined(separator:) and flatten()](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025136.html)
-- [[Pitch] Rename flatten() to joined() and give joined() for string sequences the empty string as the default parameter](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025234.html)
+- [[Pitch] Unify joined(separator:) and flatten()](https://forums.swift.org/t/pitch-unify-joined-separator-and-flatten/3505)
+- [[Pitch] Rename flatten() to joined() and give joined() for string sequences the empty string as the default parameter](https://forums.swift.org/t/pitch-rename-flatten-to-joined-and-give-joined-for-string-sequences-the-empty-string-as-the-default-parameter/3522)
## Motivation
diff --git a/proposals/0134-rename-string-properties.md b/proposals/0134-rename-string-properties.md
index 6e5398ed48..6d9abf3cd9 100644
--- a/proposals/0134-rename-string-properties.md
+++ b/proposals/0134-rename-string-properties.md
@@ -2,17 +2,17 @@
* Proposal: [SE-0134](0134-rename-string-properties.md)
* Authors: [Xiaodi Wu](https://github.com/xwu), [Erica Sadun](https://github.com/erica)
-* Review Manager: [Chris Lattner](http://github.com/lattner)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000266.html)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-revision-se-0134-rename-two-utf8-related-properties-on-string/3576)
* Implementation: [apple/swift#3816](https://github.com/apple/swift/pull/3816)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/aea8b836d21051076663c5692ec1d09bb3222527/proposals/0134-rename-string-properties.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/aea8b836d21051076663c5692ec1d09bb3222527/proposals/0134-rename-string-properties.md)
## Introduction
This proposal removes `nulTerminatedUTF8` and renames `nulTerminatedUTF8CString` to enhance clarity and reduce mismatch between user expectations and the Swift programming language.
-Swift-evolution thread: [Discussion thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025378.html)
+Swift-evolution thread: [Discussion thread](https://forums.swift.org/t/draft-fix-a-typo-in-two-string-methods/3524)
## Motivation
diff --git a/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md b/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
index fd5f610baf..ef8c7fbad4 100644
--- a/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
+++ b/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0135](0135-package-manager-support-for-differentiating-packages-by-swift-version.md)
* Author: [Anders Bertelrud](https://github.com/abertelrud)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/025955.html)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0135-package-manager-support-for-differentiating-packages-by-swift-version/3687)
## Introduction
diff --git a/proposals/0136-memory-layout-of-values.md b/proposals/0136-memory-layout-of-values.md
index bc9b8463a8..9705baaa85 100644
--- a/proposals/0136-memory-layout-of-values.md
+++ b/proposals/0136-memory-layout-of-values.md
@@ -3,15 +3,15 @@
* Proposal: [SE-0136](0136-memory-layout-of-values.md)
* Author: [Xiaodi Wu](https://github.com/xwu)
* Review Manager: [Dave Abrahams](https://github.com/dabrahams)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/026164.html)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0136-memory-layout-of-values/3760)
* Implementation: [apple/swift#4041](https://github.com/apple/swift/pull/4041)
## Introduction
This proposal is to introduce, as a bugfix, a replacement for `sizeofValue(_:)` and related functions.
-Swift-evolution thread: [MemoryLayout for a value](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/025890.html)
+Swift-evolution thread: [MemoryLayout for a value](https://forums.swift.org/t/memorylayout-for-a-value/3671)
## Motivation
diff --git a/proposals/0137-avoiding-lock-in.md b/proposals/0137-avoiding-lock-in.md
index 7cc0ec72a0..43136b648a 100644
--- a/proposals/0137-avoiding-lock-in.md
+++ b/proposals/0137-avoiding-lock-in.md
@@ -3,15 +3,15 @@
* Proposal: [SE-0137](0137-avoiding-lock-in.md)
* Authors: [Dave Abrahams](https://github.com/dabrahams), [Dmitri Gribenko](https://github.com/gribozavr)
* Review Manager: [John McCall](https://github.com/rjmccall)
-* Status: **Implemented (Swift 3)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160815/026300.html)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0137-avoiding-lock-in-to-legacy-protocol-designs/3781)
## Introduction
We propose to deprecate or move protocols that shouldn't be a part of
the standard library's public API going forward.
-Swift-evolution threads: [Late Pitch](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/026071.html), [Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/026103.html)
+Swift-evolution threads: [Late Pitch](https://forums.swift.org/t/late-pitch-deprecations-moves-and-renames/3723), [Review](https://forums.swift.org/t/review-se-0137-avoiding-lock-in-to-legacy-protocol-designs/3739)
## Motivation
diff --git a/proposals/0138-unsaferawbufferpointer.md b/proposals/0138-unsaferawbufferpointer.md
index 61b3219650..b425d8356a 100644
--- a/proposals/0138-unsaferawbufferpointer.md
+++ b/proposals/0138-unsaferawbufferpointer.md
@@ -4,7 +4,7 @@
* Author: [Andrew Trick](https://github.com/atrick)
* Review manager: [Dave Abrahams](https://github.com/dabrahams)
* Status: **Implemented (Swift 3.0.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/027167.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0138-unsaferawbufferpointer/4063)
Contents:
- [Introduction](#introduction)
@@ -32,7 +32,7 @@ for binding memory to a type for subsequent normal typed
access. However, migration is not always straightforward because
SE-0107 provided only minimal support for raw pointers. Extending raw
pointer support to the `UnsafeBufferPointer` type will fill in this
-funcionality gap. This is especially important for code that currently
+functionality gap. This is especially important for code that currently
views "raw" bytes of memory as
`UnsafeBufferPointer`. Converting between `UInt8` and the
client's element type at every API transition is difficult to do
@@ -42,12 +42,8 @@ changing the type the represents a view into raw bytes to
[UnsafeRawPointer Migration Guide](https://swift.org/migration-guide/se-0107-migrate.html).
Swift-evolution threads:
-- [Week #1](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/thread.html#26173)
-- [Week #2](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160815/thread.html#26254)
-- [Week #3](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/thread.html#26553)
-- [Week #4 (1)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160829/thread.html#26812)
-- [Week #4 (2)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160829/thread.html#26844)
-- [Week #5](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/thread.html#26947)
+- [Pitch](https://forums.swift.org/t/late-pitch-unsafebytes-proposal/3762)
+- [Review thread 1](https://forums.swift.org/t/se-0138-unsafebytes/3926), [Review thread 2](https://forums.swift.org/t/review-se-0138-unsafebytes/3917)
## Motivation
@@ -73,7 +69,7 @@ is natural for the same type that encapsulates a raw pointer and
length to also allow clients to view that memory as raw bytes without the
need to explicitly bind the memory type each time memory is
accessed. This would also improve performance in some cases that I've
-encoutered by avoiding array copies. Let's call this new type
+encountered by avoiding array copies. Let's call this new type
`Unsafe[Mutable]RawBufferPointer`.
Any array could be viewed as `UnsafeRawBufferPointer`, and that raw
@@ -492,7 +488,7 @@ collection of bytes, so there's no loss in functionality:
```swift
public final class BufferedOutputByteStream: OutputByteStream {
// FIXME: For inmemory implementation we should be share this buffer with OutputByteStream.
- // One way to do this is by allowing OuputByteStream to install external buffers.
+ // One way to do this is by allowing OutputByteStream to install external buffers.
private var contents = [UInt8]()
override final func writeImpl(_ bytes: UnsafeRawBufferPointer) {
diff --git a/proposals/0139-bridge-nsnumber-and-nsvalue.md b/proposals/0139-bridge-nsnumber-and-nsvalue.md
index 8a02fdd678..c6d3a65d1b 100644
--- a/proposals/0139-bridge-nsnumber-and-nsvalue.md
+++ b/proposals/0139-bridge-nsnumber-and-nsvalue.md
@@ -4,7 +4,7 @@
* Author: [Joe Groff](https://github.com/jckarter)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.0.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160912/027060.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/se-0139-bridge-numeric-types-to-nsnumber-and-cocoa-structs-to-nsvalue/4004)
## Introduction
@@ -13,7 +13,7 @@ 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.
-Swift-evolution thread: [here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026560.html)
+Swift-evolution thread: [here](https://forums.swift.org/t/proposal-draft-bridge-numeric-types-to-nsnumber-and-cocoa-structs-to-nsvalue/3841)
## Motivation
diff --git a/proposals/0140-bridge-optional-to-nsnull.md b/proposals/0140-bridge-optional-to-nsnull.md
index 201af6ede0..e5eca4d8a5 100644
--- a/proposals/0140-bridge-optional-to-nsnull.md
+++ b/proposals/0140-bridge-optional-to-nsnull.md
@@ -4,7 +4,7 @@
* Author: [Joe Groff](https://github.com/jckarter)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.0.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160912/027062.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0140-bridge-optional-as-its-payload-or-nsnull/4005)
## Introduction
@@ -42,7 +42,7 @@ ObjCClass().imported(s1)
ObjCClass().imported(s2)
```
-Swift-evolution thread: [here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026561.html)
+Swift-evolution thread: [here](https://forums.swift.org/t/proposal-draft-bridge-optional-as-its-payload-or-nsnull/3842)
## Motivation
@@ -195,9 +195,11 @@ error, so should fail early at runtime:
This point of view is understandable, but is inconsistent with how Swift itself
dynamically treats Optionals inside Anys:
+```swift
let a: Int? = 3
let b = a as Any
let c = a as! Int // Casts '3' out of the Optional as a non-optional Int
+```
And while it's true that Cocoa uses `NSNull` sparingly, it *is* the standard
sentinel used in the few places where a null-like object is expected, such as
diff --git a/proposals/0141-available-by-swift-version.md b/proposals/0141-available-by-swift-version.md
index 6d2b9f289d..b3bc4fda3e 100644
--- a/proposals/0141-available-by-swift-version.md
+++ b/proposals/0141-available-by-swift-version.md
@@ -4,7 +4,7 @@
* Author: [Graydon Hoare](https://github.com/graydon)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027604.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0141-availability-by-swift-version/4190)
* Bug: [SR-2709](https://bugs.swift.org/browse/SR-2709)
## Introduction
@@ -17,8 +17,8 @@ It does not currently support indicating declaration lifecycle relative to
Swift language versions. This proposal seeks to extend it to do so.
Swift-evolution threads:
- [Draft](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/027213.html),
-[Review](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/027247.html)
+[Draft](https://forums.swift.org/t/draft-availability-by-swift-version/4083),
+[Review](https://forums.swift.org/t/review-se-0141-availability-by-swift-version/4096)
## Motivation
diff --git a/proposals/0142-associated-types-constraints.md b/proposals/0142-associated-types-constraints.md
index f364a242ee..2c561ef782 100644
--- a/proposals/0142-associated-types-constraints.md
+++ b/proposals/0142-associated-types-constraints.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0142](0142-associated-types-constraints.md)
* Authors: [David Hart](https://github.com/hartbit), [Jacob Bandes-Storch](https://github.com/jtbandes), [Doug Gregor](https://github.com/DougGregor)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027606.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0142-permit-where-clauses-to-constrain-associated-types/4191)
* Bugs: [SR-4506](https://bugs.swift.org/browse/SR-4506)
## Introduction
@@ -16,11 +16,8 @@ the same expressive power as generic type parameters.
This proposal was discussed twice on the Swift Evolution list in the following
threads:
-* [\[Completing Generics\] Arbitrary requirements in protocols](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014667.html)
-* [Proposal] More Powerful Constraints for Associated Types
- - [Week #1](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015625.html)
- - [Week #2](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015753.html)
- - [Week #3](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016354.html)
+* [\[Completing Generics\] Arbitrary requirements in protocols](https://forums.swift.org/t/completing-generics-arbitrary-requirements-in-protocols/2135)
+* [\[Proposal\] More Powerful Constraints for Associated Types](https://forums.swift.org/t/proposal-more-powerful-constraints-for-associated-types/2328)
## Motivation
@@ -101,7 +98,7 @@ protocol Collection : Sequence {
But as Douglas notes himself, that syntax is ambiguous since we adopted the
generic `where` clause at the end of declarations of the following proposal:
-[SE-0081: Move where clause to end of declaration](https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md). For those reasons, it might be wiser not to introduce the shorthand syntax.
+[SE-0081: Move where clause to end of declaration](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0081-move-where-expression.md). For those reasons, it might be wiser not to introduce the shorthand syntax.
## Acknowledgements
diff --git a/proposals/0143-conditional-conformances.md b/proposals/0143-conditional-conformances.md
index b77e86d9a2..f6cfaf5a66 100644
--- a/proposals/0143-conditional-conformances.md
+++ b/proposals/0143-conditional-conformances.md
@@ -4,8 +4,8 @@
* Author: [Doug Gregor](https://github.com/DougGregor)
* Review Manager: [Joe Groff](https://github.com/jckarter)
* Status: **Implemented (Swift 4.2)**
-* Decision Notes: [Review extended](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161107/028745.html), [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028888.html)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/91725ee83fa34c81942a634dcdfa9d2441fbd853/proposals/0143-conditional-conformances.md)
+* Decision Notes: [Review extended](https://forums.swift.org/t/review-se-0143-conditional-conformances/4130/10), [Rationale](https://forums.swift.org/t/accepted-se-0143-conditional-conformances/4537)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/91725ee83fa34c81942a634dcdfa9d2441fbd853/proposals/0143-conditional-conformances.md)
## Introduction
@@ -27,7 +27,7 @@ manifesto](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#
because it's something that fits naturally into the generics model and
is expected to have a high impact on the Swift standard library.
-Swift-evolution thread: [here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027300.html)
+Swift-evolution thread: [here](https://forums.swift.org/t/proposal-draft-conditional-conformances/4110)
## Motivation
@@ -396,7 +396,7 @@ There is a variation on that type,
ReversedRandomAccessCollection: RandomAccessCollection
```
- that additionaly conforms to `RandomAccessCollection` when its base does.
+ that additionally conforms to `RandomAccessCollection` when its base does.
Users create these types via the `reversed()` extension method on
`BidirectionalCollection` and `RandomAccessCollection` respectively.
diff --git a/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md b/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
index 3268774cf5..3b5d3a9ea1 100644
--- a/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
+++ b/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
@@ -2,9 +2,9 @@
* Proposal: [SE-0144](0144-allow-single-dollar-sign-as-valid-identifier.md)
* Author: [Ankur Patel](https://github.com/ankurp)
-* Review manager: [Chris Lattner](http://github.com/lattner)
+* Review manager: [Chris Lattner](https://github.com/lattner)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000292.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0144-allow-single-dollar-sign-as-a-valid-identifier/4340)
## Introduction
diff --git a/proposals/0145-package-manager-version-pinning.md b/proposals/0145-package-manager-version-pinning.md
index d7b07f386e..6900359fa2 100644
--- a/proposals/0145-package-manager-version-pinning.md
+++ b/proposals/0145-package-manager-version-pinning.md
@@ -4,9 +4,9 @@
* Author: [Daniel Dunbar](https://github.com/ddunbar), [Ankit Aggarwal](https://github.com/aciidb0mb3r), [Graydon Hoare](https://github.com/graydon)
* Review Manager: [Anders Bertelrud](https://github.com/abertelrud)
* Status: **Implemented (Swift 3.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-December/000302.html)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/91725ee83fa34c81942a634dcdfa9d2441fbd853/proposals/0145-package-manager-version-pinning.md)
-* Previous Discussion: [Email Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161107/028758.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/swift-evolution-accepted-se-0145-package-manager-version-pinning-revised/4653)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/91725ee83fa34c81942a634dcdfa9d2441fbd853/proposals/0145-package-manager-version-pinning.md)
+* Previous Discussion: [Email Thread](https://forums.swift.org/t/review-se-0145-package-manager-version-pinning/4405/15)
## Introduction
@@ -208,7 +208,7 @@ update` behavior described above).
If a package author does check the file into source control, the effect will be
that anyone developing directly on this package will end up sharing the same
-dependency versions (and modifications will be commited as part of the SCM
+dependency versions (and modifications will be committed as part of the SCM
history).
The automatic pinning behavior is an extension of the behaviors above, and works
@@ -366,7 +366,7 @@ specification in the manifest (which is the "requirement"). The meaning of pin
connotes this transient relationship between the pin action and the underlying
dependency.
-In constrast, not only does lock have the wrong connotation, but it also is a
+In contrast, not only does lock have the wrong connotation, but it also is a
heavily overloaded word which can lead to confusion. For example, if the package
manager used POSIX file locking to prevent concurrent manipulation of packages
(a feature we intend to implement), and we also referred to the pinning files as
diff --git a/proposals/0146-package-manager-product-definitions.md b/proposals/0146-package-manager-product-definitions.md
index 5cd0a42429..ce87eeb8fe 100644
--- a/proposals/0146-package-manager-product-definitions.md
+++ b/proposals/0146-package-manager-product-definitions.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0146](0146-package-manager-product-definitions.md)
* Author: [Anders Bertelrud](https://github.com/abertelrud)
* Review manager: Daniel Dunbar
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000298.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/review-se-0146-package-manager-product-definitions/4540/2)
* Bug: [SR-3606](https://bugs.swift.org/browse/SR-3606)
## Introduction
diff --git a/proposals/0147-move-unsafe-initialize-from.md b/proposals/0147-move-unsafe-initialize-from.md
index 52251f4631..7964d5d408 100644
--- a/proposals/0147-move-unsafe-initialize-from.md
+++ b/proposals/0147-move-unsafe-initialize-from.md
@@ -4,7 +4,7 @@
* Author: [Ben Cohen](https://github.com/airspeedswift)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 3.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029945.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0147-move-unsafemutablepointer-initialize-from-to-unsafemutablebufferpointer/4823)
* Implementation: [apple/swift#6601](https://github.com/apple/swift/pull/6601)
## Introduction
@@ -54,7 +54,7 @@ Therefore:
- Over-allocating the destination buffer relative to `underestimatedCount` is valid and simply results in sequence underflow with potentially uninitialized buffer memory (a likely case with arrays that reserve more than they need).
- The source sequence's actual count may exceed both `underestimatedCount` and the destination buffer size, resulting in sequence overflow. This is also valid and handled by returning an iterator to the uncopied elements as an overflow sequence.
-A matching change should also be made to `UnsafeRawBufferPointer.initializeMemory(from:)`. The one difference is that for convenience this should return an `UnsafeMutableBufferPointer` of the (typed) intialized elements instead of an index into the raw buffer.
+A matching change should also be made to `UnsafeRawBufferPointer.initializeMemory(from:)`. The one difference is that for convenience this should return an `UnsafeMutableBufferPointer` of the (typed) initialized elements instead of an index into the raw buffer.
## Detailed design
diff --git a/proposals/0148-generic-subscripts.md b/proposals/0148-generic-subscripts.md
index dfab2598ef..1eb2e0dae8 100644
--- a/proposals/0148-generic-subscripts.md
+++ b/proposals/0148-generic-subscripts.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0148](0148-generic-subscripts.md)
* Author: [Chris Eidhof](https://github.com/chriseidhof)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/031048.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0148-generic-subscripts/5017)
* Bug: [SR-115](https://bugs.swift.org/browse/SR-115)
## Introduction
@@ -29,7 +29,7 @@ extension JSON {
}
```
-Swift-evolution thread: [Generic Subscripts](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030064.html).
+Swift-evolution thread: [Generic Subscripts](https://forums.swift.org/t/generic-subscripts/4858).
## Motivation
@@ -38,7 +38,7 @@ Currently, subscripts can't be generic. This is limiting in a number of ways:
- Some subscripts are very specific and could be made more generic.
- Some generic methods would feel more natural as a subscript, but currently can't be. This also makes it impossible to use them as lvalues.
-This feature is also mentioned in the generics manifesto under [generic subscripts](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts). The [Rationalizing Sequence end-operation names](https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md) proposal could greatly benefit from this, as well as the ideas in the [String Manifesto](https://github.com/apple/swift/blob/master/docs/StringManifesto.md).
+This feature is also mentioned in the generics manifesto under [generic subscripts](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts). The [Rationalizing Sequence end-operation names](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md) proposal could greatly benefit from this, as well as the ideas in the [String Manifesto](https://github.com/apple/swift/blob/master/docs/StringManifesto.md).
## Proposed solution
@@ -64,7 +64,7 @@ Adding default arguments would unify the compiler's handling of subscripts and f
## Source compatibility
-This is a purely additive change. We don't propose changing the Standard Library to use this new feature, that should be part of a separate proposal. (Likewise, we should consider making subscripts `throws` in a [separate proposal](https://github.com/brentdax/swift-evolution/blob/throwing-properties/proposals/0000-throwing-properties.md)).
+This is a purely additive change. We don't propose changing the Standard Library to use this new feature, that should be part of a separate proposal. (Likewise, we should consider making subscripts `throws` in a [separate proposal](https://github.com/beccadax/swift-evolution/blob/throwing-properties/proposals/0000-throwing-properties.md)).
## Effect on ABI stability
diff --git a/proposals/0149-package-manager-top-of-tree.md b/proposals/0149-package-manager-top-of-tree.md
index cef6819403..8b30f65cde 100644
--- a/proposals/0149-package-manager-top-of-tree.md
+++ b/proposals/0149-package-manager-top-of-tree.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0149](0149-package-manager-top-of-tree.md)
* Author: [Boris Bügling](https://github.com/neonichu)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031427.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0149-package-manager-support-for-top-of-tree-development/5072)
* Bug: [SR-3709](https://bugs.swift.org/browse/SR-3709)
## Introduction
diff --git a/proposals/0150-package-manager-branch-support.md b/proposals/0150-package-manager-branch-support.md
index 4756651ffa..6fa969c889 100644
--- a/proposals/0150-package-manager-branch-support.md
+++ b/proposals/0150-package-manager-branch-support.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0150](0150-package-manager-branch-support.md)
* Author: [Boris Bügling](https://github.com/neonichu)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031428.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0150-package-manager-support-for-branches/5074)
* Bug: [SR-666](https://bugs.swift.org/browse/SR-666)
## Introduction
diff --git a/proposals/0151-package-manager-swift-language-compatibility-version.md b/proposals/0151-package-manager-swift-language-compatibility-version.md
index 8bb92994e0..e9421cf04b 100644
--- a/proposals/0151-package-manager-swift-language-compatibility-version.md
+++ b/proposals/0151-package-manager-swift-language-compatibility-version.md
@@ -1,10 +1,10 @@
# Package Manager Swift Language Compatibility Version
* Proposal: [SE-0151](0151-package-manager-swift-language-compatibility-version.md)
-* Authors: [Daniel Dunbar](https://github.com/ddunbar), [Rick Ballard](http://github.com/rballard)
+* Authors: [Daniel Dunbar](https://github.com/ddunbar), [Rick Ballard](https://github.com/rballard)
* Review Manager: [Anders Bertelrud](https://github.com/abertelrud)
* Status: **Implemented (Swift 3.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032021.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0151-package-manager-swift-language-compatibility-version/5183)
* Bug: [SR-3964](https://bugs.swift.org/browse/SR-3964)
## Introduction
diff --git a/proposals/0152-package-manager-tools-version.md b/proposals/0152-package-manager-tools-version.md
index 80e5d27a7e..92394f4156 100644
--- a/proposals/0152-package-manager-tools-version.md
+++ b/proposals/0152-package-manager-tools-version.md
@@ -4,7 +4,7 @@
* Author: [Rick Ballard](https://github.com/rballard)
* Review Manager: [Anders Bertelrud](https://github.com/abertelrud)
* Status: **Implemented (Swift 3.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032023.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0152-package-manager-tools-version/5184)
* Bug: [SR-3965](https://bugs.swift.org/browse/SR-3965)
## Introduction
diff --git a/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md b/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
index 33efbdcfcf..f5005565bd 100644
--- a/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
+++ b/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
@@ -3,16 +3,11 @@
* Proposal: [SE-0153](0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md)
* Author: [Torin Kwok](https://github.com/TorinKwok)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Accepted**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033357.html)
+* Status: **Rejected**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0153-compensate-for-the-inconsistency-of-nscopying-s-behaviour/5341), [Additional Commentary](https://forums.swift.org/t/addressing-unimplemented-evolution-proposals/40322)
* Bug: [SR-4538](https://bugs.swift.org/browse/SR-4538)
-
+**Note**: This proposal was initially accepted without an implementation on 2017-03-01, and has not been implemented since. The Core Team has decided to retroactively reject the proposal.
## Introduction
@@ -26,8 +21,7 @@ This proposal is intent on proposing several solutions to this inconsistency.
## Swift-evolution thread
-- [@NSCopying currently does not affect initializers (from *The Week Of Monday 23 January 2017 Archive*)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/031049.html)
-- [@NSCopying currently does not affect initializers (from *The Week Of Monday 30 January 2017 Archive*)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031162.html)
+[@NSCopying currently does not affect initializers](https://forums.swift.org/t/nscopying-currently-does-not-affect-initializers/5019)
## Motivation
diff --git a/proposals/0154-dictionary-key-and-value-collections.md b/proposals/0154-dictionary-key-and-value-collections.md
index 0258383838..f5ad8d6d71 100644
--- a/proposals/0154-dictionary-key-and-value-collections.md
+++ b/proposals/0154-dictionary-key-and-value-collections.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0154](0154-dictionary-key-and-value-collections.md)
* Author: [Nate Cook](https://github.com/natecook1000)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/033159.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0154-provide-custom-collections-for-dictionary-keys-and-values/5322)
## Introduction
@@ -12,7 +12,7 @@ This proposal addresses significant unexpected performance gaps when using dicti
New collection types provide efficient key lookup and mutable access to dictionary values, allowing in-place updates and copy-on-write optimization of stored values. The addition of these new types impacts the standard library ABI, since we won't be able to use types aliases from the existing types for `keys` and `values`.
-Swift-evolution thread: [[Proposal Draft] Provide Custom Collections for Dictionary Keys and Values](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027815.html)
+Swift-evolution thread: [[Proposal Draft] Provide Custom Collections for Dictionary Keys and Values](https://forums.swift.org/t/proposal-draft-provide-custom-collections-for-dictionary-keys-and-values/4244)
## Motivation
diff --git a/proposals/0155-normalize-enum-case-representation.md b/proposals/0155-normalize-enum-case-representation.md
index 900033849a..8e0474d166 100644
--- a/proposals/0155-normalize-enum-case-representation.md
+++ b/proposals/0155-normalize-enum-case-representation.md
@@ -3,10 +3,10 @@
* Proposal: [SE-0155][]
* Authors: [Daniel Duan][], [Joe Groff][]
* Review Manager: [John McCall][]
-* Status: **Accepted with revisions**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html)
-* Previous Revision: [1][Revision 1]
-* Bug: [SR-4691](https://bugs.swift.org/browse/SR-4691)
+* Status: **Implemented (Swift 3.0)**
+* Decision Notes: [Rationale][]
+* Previous Revision: [1][Revision 1], [Originally Accepted Proposal][], [Expired Proposal][]
+* Bugs: [SR-4691](https://bugs.swift.org/browse/SR-4691), [SR-12206](https://bugs.swift.org/browse/SR-12206), [SR-12229](https://bugs.swift.org/browse/SR-12229)
## Introduction
@@ -181,61 +181,6 @@ enum Tree {
}
```
-### Pattern Consistency
-
-*(The following enum will be used throughout code snippets in this section).*
-
-```swift
-indirect enum Expr {
- case variable(name: String)
- case lambda(parameters: [String], body: Expr)
-}
-```
-
-Compared to patterns in Swift 3, matching against enum cases will follow
-stricter rules. This is a consequence of no longer relying on tuple patterns.
-
-When an associated value has a label, the sub-pattern must include the label
-exactly as declared. There are two variants that should look familiar to Swift
-3 users. Variant 1 allows user to bind the associated value to arbitrary name in
-the pattern by requiring the label:
-
-```swift
-case .variable(name: let x) // okay
-case .variable(x: let x) // compile error; there's no label `x`
-case .lambda(parameters: let params, body: let body) // Okay
-case .lambda(params: let params, body: let body) // error: 1st label mismatches
-```
-
-User may choose not to use binding names that differ from labels. In this
-variant, the corresponding value will bind to the label, resulting in this
-shorter form:
-
-```swift
-case .variable(let name) // okay, because the name is the same as the label
-case .lambda(let parameters, let body) // this is okay too, same reason.
-case .variable(let x) // compiler error. label must appear one way or another.
-case .lambda(let params, let body) // compiler error, same reason as above.
-```
-
-Only one of these variants may appear in a single pattern. Swift compiler will
-raise a compile error for mixed usage.
-
-```swift
-case .lambda(parameters: let params, let body) // error, can not mix the two.
-```
-
-Some patterns will no longer match enum cases. For example, all associated
-values can bind as a tuple in Swift 3, this will no longer work after this
-proposal:
-
-```swift
-// deprecated: matching all associated values as a tuple
-if case let .lambda(f) = anLambdaExpr {
- evaluateLambda(parameters: f.parameters, body: f.body)
-}
-```
-
## Source compatibility
Despite a few additions, case declaration remain mostly source-compatible with
@@ -244,12 +189,6 @@ Case Declaration".
Syntax for case constructor at use site remain source-compatible.
-A large portion of pattern matching syntax for enum cases with associated values
-remain unchanged. But patterns for matching all values as a tuple, patterns that
-elide the label and binds to names that differ from the labels, patterns that
-include labels for some sub-patterns but the rest of them are deprecated by this
-proposal. Therefore this is a source breaking change.
-
## Effect on ABI stability and resilience
After this proposal, enum cases may have compound names. This means the standard
@@ -290,7 +229,9 @@ be introduced with alternative syntax (perhaps related to splats) later without
source-breakage. And the need to implement `Equatable` may also disappear with
auto-deriving for `Equatable` conformance.
-The previous revision of this proposal mandated that the labeled form of
+## Revision History
+
+The [first revision of this proposal][Revision 1] mandated that the labeled form of
sub-pattern (`case .elet(locals: let x, body: let y)`) be the only acceptable
pattern. Turns out the community considers this to be too verbose in some cases.
@@ -298,11 +239,35 @@ A drafted version of this proposal considered allowing "overloaded" declaration
of enum cases (same full-name, but with associated values with different types).
We ultimately decided that this feature is out of the scope of this proposal.
+The [second revision of this proposal][Originally Accepted Proposal] was accepted with revisions. As originally written, the proposal required that pattern matching against an enum match either by the name of the bound variables, or by explicit labels on the parts of the associated values:
+
+```
+enum Foo {
+ case foo(bar: Int)
+}
+
+func switchFoo(x: Foo) {
+ switch x {
+ case .foo(let bar): // ok
+ case .foo(bar: let bar): // ok
+ case .foo(bar: let bas): // ok
+ case .foo(let bas): // not ok
+ }
+}
+```
+
+However, it was decided in review that this was still too restrictive and
+source-breaking, and so the core team [accepted the proposal][Rationale] with the modification that pattern matches only had to match the case declaration in arity, and case labels could be either provided or elided in their entirety, unless there was an ambiguity. Even then, as of Swift 5.2, this part of the proposal has not been implemented, and it would be a source breaking change to do so. Therefore, the "Pattern Consistency" section of the original proposal has been removed, and replaced with a ["Disambiguating pattern matches" section](https://github.com/swiftlang/swift-evolution/blob/aecced4919ab297f343dafd7235d392d8b859839/proposals/0155-normalize-enum-case-representation.md), which provided a minimal disambiguation rule for pattern matching cases that share a
+base name. This new design still had not been implemented at the time the [core team adopted a new expiration policy for unimplemented proposals](https://forums.swift.org/t/addressing-unimplemented-evolution-proposals/40322), so it has expired.
+
[SE-0155]: 0155-normalize-enum-case-representation.md
[SE-0111]: 0111-remove-arg-label-type-significance.md
[Daniel Duan]: https://github.com/dduan
[Joe Groff]: https://github.com/jckarter
[John McCall]: https://github.com/rjmccall
-[TJs comment]: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030614.html
-[Revision 1]: https://github.com/apple/swift-evolution/blob/43ca098355762014f53e1b54e02d2f6a01253385/proposals/0155-normalize-enum-case-representation.md
-[Normalize Enum Case Representation (rev. 2)]: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033626.html
+[TJs comment]: https://forums.swift.org/t/draft-compound-names-for-enum-cases/4933/33
+[Revision 1]: https://github.com/swiftlang/swift-evolution/blob/43ca098355762014f53e1b54e02d2f6a01253385/proposals/0155-normalize-enum-case-representation.md
+[Normalize Enum Case Representation (rev. 2)]: https://forums.swift.org/t/normalize-enum-case-representation-rev-2/5395
+[Originally Accepted Proposal]: https://github.com/swiftlang/swift-evolution/blob/4cbb1f1fa836496d4bfba95c4b78a9754690956d/proposals/0155-normalize-enum-case-representation.md
+[Expired Proposal]: https://github.com/swiftlang/swift-evolution/blob/aecced4919ab297f343dafd7235d392d8b859839/proposals/0155-normalize-enum-case-representation.md
+[Rationale]: https://forums.swift.org/t/accepted-se-0155-normalize-enum-case-representation/5732
diff --git a/proposals/0156-subclass-existentials.md b/proposals/0156-subclass-existentials.md
index 1ca4d416a6..a3107aef79 100644
--- a/proposals/0156-subclass-existentials.md
+++ b/proposals/0156-subclass-existentials.md
@@ -1,17 +1,17 @@
# Class and Subtype existentials
* Proposal: [SE-0156](0156-subclass-existentials.md)
-* Authors: [David Hart](http://github.com/hartbit), [Austin Zheng](http://github.com/austinzheng)
+* Authors: [David Hart](https://github.com/hartbit), [Austin Zheng](https://github.com/austinzheng)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034123.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0156-class-and-subtype-existentials/5477)
* Bug: [SR-4296](https://bugs.swift.org/browse/SR-4296)
## Introduction
This proposal brings more expressive power to the type system by allowing Swift to represent existentials of classes and subtypes which conform to protocols.
-[Mailing list discussion](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/031066.html)
+[Mailing list discussion](https://forums.swift.org/t/subclass-existentials/5024)
## Motivation
@@ -190,7 +190,7 @@ let myViewController = MyViewController()
myViewController.setup(UIViewController())
```
-The previous code continues to compile but still crashs if the Objective-C code calls a method of `UITableViewDataSource` or `UITableViewDelegate`. But if this proposal is accepted and implemented as-is, the Objective-C code will be imported in Swift 4 mode as:
+The previous code continues to compile but still crashes if the Objective-C code calls a method of `UITableViewDataSource` or `UITableViewDelegate`. But if this proposal is accepted and implemented as-is, the Objective-C code will be imported in Swift 4 mode as:
```swift
class MyViewController {
@@ -205,7 +205,7 @@ That would then cause the Swift code run in version 4 mode to fail to compile wi
An alternative solution to the `class`/`AnyObject` duplication was to keep both, redefine `AnyObject` as `typealias AnyObject = class` and favor the latter when used as a type name.
The [reviewed version of the
-proposal](https://github.com/apple/swift-evolution/blob/78da25ec4acdc49ad9b68fb58300e49c33bc6355/proposals/0156-subclass-existentials.md)
+proposal](https://github.com/swiftlang/swift-evolution/blob/78da25ec4acdc49ad9b68fb58300e49c33bc6355/proposals/0156-subclass-existentials.md)
included rules that required the class type (or `AnyObject`) to be
first within the protocol composition, e.g., `AnyObject & Protocol1`
was well-formed but `Protocol1 & AnyObject` would produce a compiler
@@ -214,4 +214,4 @@ rules; see the decision notes at the top for more information.
## Acknowledgements
-Thanks to [Austin Zheng](http://github.com/austinzheng) and [Matthew Johnson](https://github.com/anandabits) who brought a lot of attention to existentials in this mailing-list and from whom most of the ideas in the proposal come from.
+Thanks to [Austin Zheng](https://github.com/austinzheng) and [Matthew Johnson](https://github.com/anandabits) who brought a lot of attention to existentials in this mailing-list and from whom most of the ideas in the proposal come from.
diff --git a/proposals/0157-recursive-protocol-constraints.md b/proposals/0157-recursive-protocol-constraints.md
index c0fea174ae..81c1328494 100644
--- a/proposals/0157-recursive-protocol-constraints.md
+++ b/proposals/0157-recursive-protocol-constraints.md
@@ -4,7 +4,7 @@
* Authors: [Douglas Gregor](https://github.com/DougGregor), [Erica Sadun](https://github.com/erica), [Austin Zheng](https://github.com/austinzheng)
* Review Manager: [John McCall](https://github.com/rjmccall)
* Status: **Implemented (Swift 4.1)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034266.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/se-0157-support-recursive-constraints-on-associated-types/5494)
* Bug: [SR-1445](https://bugs.swift.org/browse/SR-1445)
## Introduction
@@ -12,7 +12,7 @@
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).
-Further reading: [swift-evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161107/028805.html), _[Completing Generics](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#recursive-protocol-constraints-)_
+Further reading: [swift-evolution thread](https://forums.swift.org/t/pitch-plea-recursive-protocol-constraints/4507), _[Completing Generics](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#recursive-protocol-constraints-)_
## Motivation
@@ -93,7 +93,7 @@ Implementation details regarding the compiler changes necessary to implement the
found in [this document](https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6).
The second part of the solution involves updating the standard library to take advantage of the removal of this
-restriction. Such changes are made with [SE-0142](https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md)
+restriction. Such changes are made with [SE-0142](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md)
in mind, and incorporate both recursive constraints and `where` clauses. The changes necessary for this are described
in the _Detailed Design_ section below.
diff --git a/proposals/0158-package-manager-manifest-api-redesign.md b/proposals/0158-package-manager-manifest-api-redesign.md
index 07e274837f..adbe933201 100644
--- a/proposals/0158-package-manager-manifest-api-redesign.md
+++ b/proposals/0158-package-manager-manifest-api-redesign.md
@@ -3,9 +3,9 @@
* Proposal: [SE-0158](0158-package-manager-manifest-api-redesign.md)
* Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
* Review Manager: [Rick Ballard](https://github.com/rballard)
-* Status: **Implemented (Swift 4)**
+* Status: **Implemented (Swift 4.0)**
* Bug: [SR-3949](https://bugs.swift.org/browse/SR-3949)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033989.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0158-package-manager-manifest-api-redesign/5468)
## Introduction
@@ -160,7 +160,7 @@ access modifier is `public` for all APIs unless specified.
"Foo")` instead of `.product(name: "Foo", package: nil)`.
If
- [SE-0155](https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md)
+ [SE-0155](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md)
is accepted, we can directly add a default value. Otherwise, we will use a
static factory method to provide default value for `package`.
@@ -218,7 +218,7 @@ access modifier is `public` for all APIs unless specified.
* Remove implicit target dependency rule for test targets.
There is an implicit test target dependency rule: a test target "FooTests"
- implicity depends on a target "Foo", if "Foo" exists and "FooTests" doesn't
+ implicitly depends on a target "Foo", if "Foo" exists and "FooTests" doesn't
explicitly declare any dependency. We propose to remove this rule because:
1. It is a non obvious "magic" rule that has to be learned.
@@ -456,7 +456,7 @@ access modifier is `public` for all APIs unless specified.
.package(url: "/SwiftyJSON", "1.2.3"..."1.2.8"),
```
* As a slight modification to the
- [branch proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md),
+ [branch proposal](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md),
we will add cases for specifying a branch or revision, rather than
adding factory methods for them:
@@ -594,7 +594,7 @@ let package = Package(
The above changes will be implemented only in the new Package Description v4
library. The v4 runtime library will release with Swift 4 and packages will be
able to opt-in into it as described by
-[SE-0152](https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md).
+[SE-0152](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md).
There will be no automatic migration feature for updating the manifests from v3
to v4. To indicate the replacements of old APIs, we will annotate them using
@@ -614,7 +614,7 @@ the v3 manifest API, they will build as expected.
A package which needs to support both Swift 3 and Swift 4 tools will need to
stay on the v3 manifest API and support the Swift 3 language version for its
sources, using the API described in the proposal
-[SE-0151](https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md).
+[SE-0151](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md).
An existing package which wants to use the new v4 manifest APIs will need to bump its
minimum tools version to 4.0 or later using the command `$ swift package tools-version
diff --git a/proposals/0159-fix-private-access-levels.md b/proposals/0159-fix-private-access-levels.md
index c2289d5194..45660527a8 100644
--- a/proposals/0159-fix-private-access-levels.md
+++ b/proposals/0159-fix-private-access-levels.md
@@ -1,14 +1,14 @@
# Fix Private Access Levels
* Proposal: [SE-0159](0159-fix-private-access-levels.md)
-* Author: [David Hart](http://github.com/hartbit)
+* Author: [David Hart](https://github.com/hartbit)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Rejected**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034902.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0159-fix-private-access-levels/5576)
## Introduction
-This proposal presents the problems that came with the the access level modifications in [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) and proposes reverting to Swift 2 behaviour.
+This proposal presents the problems that came with the the access level modifications in [SE-0025](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) and proposes reverting to Swift 2 behaviour.
## Motivation
@@ -28,7 +28,7 @@ In Swift 3 compatibility mode, the compiler will continue to treat `private` and
In Swift 4 mode, the compiler will deprecate the `fileprivate` keyword and revert the semantics of the `private` access level to be file based. The migrator will rename all uses of `fileprivate` to `private`.
-Cases where a type had `private` declarations with the same signature in different scopes will produce a compiler error. For example, the following piece of code compiles in Swift 3 compatibilty mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode.
+Cases where a type had `private` declarations with the same signature in different scopes will produce a compiler error. For example, the following piece of code compiles in Swift 3 compatibility mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode.
```swift
struct Foo {
diff --git a/proposals/0160-objc-inference.md b/proposals/0160-objc-inference.md
index 26b0890bb9..8c595e5318 100644
--- a/proposals/0160-objc-inference.md
+++ b/proposals/0160-objc-inference.md
@@ -3,9 +3,9 @@
* Proposal: [SE-0160](0160-objc-inference.md)
* Author: [Doug Gregor](https://github.com/DougGregor)
* Review Manager: [Chris Lattner](https://github.com/lattner)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000349.html)
-* Previous Revisions: [1](https://github.com/apple/swift-evolution/blob/0389b1f49fc55b1a898701c549ce89738307b9fc/proposals/0160-objc-inference.md)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0160-limiting-objc-inference/5621)
+* Previous Revisions: [1](https://github.com/swiftlang/swift-evolution/blob/0389b1f49fc55b1a898701c549ce89738307b9fc/proposals/0160-objc-inference.md)
* Implementation: [apple/swift#8379](https://github.com/apple/swift/pull/8379)
* Bug: [SR-4481](https://bugs.swift.org/browse/SR-4481)
@@ -23,7 +23,7 @@ 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.
-Swift-evolution thread: [here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017308.html) and [here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029909.html)
+Swift-evolution thread: [here](https://forums.swift.org/t/pitch-align-objc-inference-with-the-semantic-model/2563) and [here](https://forums.swift.org/t/proposal-draft-limiting-objc-inference/4812)
## Motivation
@@ -176,7 +176,7 @@ become well-formed, and the method `bar()` will continue to work as
it does today through the Objective-C runtime. Indeed, this change
is the right way forward even if Swift never supports `dynamic` in
its own runtime, following the precedent of
-[SE-0070](https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md),
+[SE-0070](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0070-optional-requirements.md),
which required the Objective-C-only protocol feature "optional
requirements" to be explicitly marked with `@objc`.
@@ -319,7 +319,7 @@ possible, but Swift does not (and, practically speaking, cannot) do
the same for protocol extensions.
A previous mini-proposal [discussed
-here](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005312.html)
+here](https://forums.swift.org/t/mini-proposal-require-nonobjc-on-members-of-objc-protocol-extensions/905)
suggested requiring `@nonobjc` for members of `@objc` protocol
extensions. However, limiting inference of `@objc` eliminates the
expectation itself, addressing the problem from a different angle.
@@ -606,6 +606,6 @@ relationship to this proposal.
# Revision history
-[Version 1](https://github.com/apple/swift-evolution/blob/0389b1f49fc55b1a898701c549ce89738307b9fc/proposals/0160-objc-inference.md)
+[Version 1](https://github.com/swiftlang/swift-evolution/blob/0389b1f49fc55b1a898701c549ce89738307b9fc/proposals/0160-objc-inference.md)
of this proposal did not include the use of `@objcMembers` on classes
or the use of `@objc`/`@nonobjc` on extensions to mass-annotate.
diff --git a/proposals/0161-key-paths.md b/proposals/0161-key-paths.md
index db2d6a2a50..b945854b41 100644
--- a/proposals/0161-key-paths.md
+++ b/proposals/0161-key-paths.md
@@ -3,9 +3,9 @@
* Proposal: [SE-0161](0161-key-paths.md)
* Authors: [David Smith](https://github.com/Catfish-Man), [Michael LeHew](https://github.com/mlehew), [Joe Groff](https://github.com/jckarter)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000356.html)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/55e61f459632eca2face40e571a517919f846cfb/proposals/0161-key-paths.md)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0161-smart-keypaths-better-key-value-coding-for-swift/5690)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/55e61f459632eca2face40e571a517919f846cfb/proposals/0161-key-paths.md)
## Introduction
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.
@@ -182,9 +182,9 @@ We also explored many different spellings, each with different strengths. We hav
| Case | `#keyPath` | Function Type Reference | Escape |
| --- | --- | --- | --- |
| Fully qualified | `#keyPath(Person, .friends[0].name)` | `Person.friends[0].name` | `\Person.friends[0].name` |
-| Type Inferred| `#keyPath(.friends[0].name)` |`Person.friends[0].name` | `\.friends[0].name` |
+| Type Inferred | `#keyPath(.friends[0].name)` |`Person.friends[0].name` | `\.friends[0].name` |
-While the crispness of the function-type-reference is appealing, it becomes ambigious when working with type properties. The escape-sigil variant avoids this, and remains quite readable.
+While the crispness of the function-type-reference is appealing, it becomes ambiguous when working with type properties. The escape-sigil variant avoids this, and remains quite readable.
#### Why `\`?
During review many different sigils were considered:
@@ -199,4 +199,3 @@ During review many different sigils were considered:
#### Function Type References
We think the disambiguating benefits of the escape-sigil would greatly benefit function type references, but such considerations are outside the scope of this proposal.
-
diff --git a/proposals/0162-package-manager-custom-target-layouts.md b/proposals/0162-package-manager-custom-target-layouts.md
index e4d3d44155..78d428e350 100644
--- a/proposals/0162-package-manager-custom-target-layouts.md
+++ b/proposals/0162-package-manager-custom-target-layouts.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0162](0162-package-manager-custom-target-layouts.md)
* Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
* Review Manager: [Rick Ballard](https://github.com/rballard)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035471.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0162-package-manager-custom-target-layouts/5647)
* Bug: [SR-29](https://bugs.swift.org/browse/SR-29)
## Introduction
@@ -91,7 +91,7 @@ remember.
consider upgrading this to its own type to allow per-file build settings.
The new type would conform to `CustomStringConvertible`, so existing
declarations would continue to work (except where the strings were
- constructed programatically).
+ constructed programmatically).
* `exclude`: This property can be used to exclude certain files and
directories from being picked up as sources. Exclude paths are relative
diff --git a/proposals/0163-string-revision-1.md b/proposals/0163-string-revision-1.md
index 41491680bb..f584cc67f7 100644
--- a/proposals/0163-string-revision-1.md
+++ b/proposals/0163-string-revision-1.md
@@ -1,12 +1,12 @@
# String Revision: Collection Conformance, C Interop, Transcoding
* Proposal: [SE-0163](0163-string-revision-1.md)
-* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](http://github.com/dabrahams/)
+* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](https://github.com/dabrahams/)
* Review Manager: [John McCall](https://github.com/rjmccall)
-* Status: **Implemented (Swift 4)**
+* Status: **Implemented (Swift 4.0)**
* Revision: 2
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/7513547ddac66b06770a1fd620aad915d75987ff/proposals/0163-string-revision-1.md)
-* Decision Notes: [Rationale #1](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035919.html), [Rationale #2](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170515/036728.html)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/7513547ddac66b06770a1fd620aad915d75987ff/proposals/0163-string-revision-1.md)
+* Decision Notes: [Rationale #1](https://forums.swift.org/t/accepted-se-0163-string-revision-collection-conformance-c-interop-transcoding/5716/2), [Rationale #2](https://forums.swift.org/t/accepted-se-0163-string-revision-collection-conformance-c-interop-transcoding/5952)
## Introduction
@@ -442,7 +442,7 @@ determined, but are not adversely affected by this proposal.
## Alternatives considered
For a more in-depth discussion of some of the trade-offs in string design, see
-the manifesto and associated [evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/thread.html#30497).
+the manifesto and associated [evolution thread](https://forums.swift.org/t/strings-in-swift-4/4939).
This proposal does not yet introduce an implicit conversion from `Substring` to
`String`. The decision on whether to add this will be deferred pending feedback
diff --git a/proposals/0164-remove-final-support-in-protocol-extensions.md b/proposals/0164-remove-final-support-in-protocol-extensions.md
index 8bf12af92d..5e807e4bd3 100644
--- a/proposals/0164-remove-final-support-in-protocol-extensions.md
+++ b/proposals/0164-remove-final-support-in-protocol-extensions.md
@@ -3,15 +3,15 @@
* Proposal: [SE-0164](0164-remove-final-support-in-protocol-extensions.md)
* Author: [Brian King](https://github.com/KingOfBrian)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000355.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0164-remove-final-support-in-protocol-extensions/5687)
* Bug: [SR-1762](https://bugs.swift.org/browse/SR-1762)
## Introduction
This proposal disallows the `final` keyword when declaring functions in protocol
extensions.
-*Discussion took place on the Swift Evolution mailing list in the [Remove support for final in protocol extensions](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033604.html) thread.*
+*Discussion took place on the Swift Evolution mailing list in the [Remove support for final in protocol extensions](https://forums.swift.org/t/draft-remove-support-for-final-in-protocol-extensions/5390) thread.*
## Motivation
diff --git a/proposals/0165-dict.md b/proposals/0165-dict.md
index e4785c6831..73897eccda 100644
--- a/proposals/0165-dict.md
+++ b/proposals/0165-dict.md
@@ -1,10 +1,10 @@
# Dictionary & Set Enhancements
-- Proposal: [SE-0165](0165-dict.md)
-- Author: [Nate Cook](https://github.com/natecook1000)
-- Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-- Status: **Implemented (Swift 4)**
-- Decision Notes: [Rationale][rationale]
+* Proposal: [SE-0165](0165-dict.md)
+* Author: [Nate Cook](https://github.com/natecook1000)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale][rationale]
## Introduction
@@ -27,9 +27,9 @@ This proposal comprises a variety of commonly (and less commonly) suggested impr
The `Dictionary` type should allow initialization from a sequence of `(Key, Value)` tuples and offer methods that merge a sequence of `(Key, Value)` tuples into a new or existing dictionary, using a closure to combine values for duplicate keys.
-- [First message of discussion thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006124.html)
-- [Initial proposal draft](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006665.html)
-- [Prior standalone proposal (SE-100)](https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md)
+- [First message of discussion thread](https://forums.swift.org/t/map-like-operation-that-returns-a-dictionary/999)
+- [Initial proposal draft](https://forums.swift.org/t/map-like-operation-that-returns-a-dictionary/999/18)
+- [Prior standalone proposal (SE-100)](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md)
`Array` and `Set` both have initializers that create a new instance from a sequence of elements. The `Array` initializer is useful for converting other sequences and collections to the "standard" collection type, while the `Set` initializer is essential for recovering set operations after performing any functional operations on a set. For example, filtering a set produces a collection without any set operations available.
@@ -513,4 +513,4 @@ extension Set {
```
[sandbox]: http://swift.sandbox.bluemix.net/#/repl/58f8e3aee785f75678f428a8
-[rationale]: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035955.html
+[rationale]: https://forums.swift.org/t/accepted-se-165-dictionary-set-enhancements/5727
diff --git a/proposals/0166-swift-archival-serialization.md b/proposals/0166-swift-archival-serialization.md
index 80310a2964..53a9a69229 100644
--- a/proposals/0166-swift-archival-serialization.md
+++ b/proposals/0166-swift-archival-serialization.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0166](0166-swift-archival-serialization.md)
* Authors: [Itai Ferber](https://github.com/itaiferber), [Michael LeHew](https://github.com/mlehew), [Tony Parker](https://github.com/parkera)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000367.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0166-swift-archival-serialization/5780)
* Implementation: [apple/swift#9004](https://github.com/apple/swift/pull/9004)
## Introduction
diff --git a/proposals/0167-swift-encoders.md b/proposals/0167-swift-encoders.md
index 12d34f4a7d..223aa7f390 100644
--- a/proposals/0167-swift-encoders.md
+++ b/proposals/0167-swift-encoders.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0167](0167-swift-encoders.md)
* Authors: [Itai Ferber](https://github.com/itaiferber), [Michael LeHew](https://github.com/mlehew), [Tony Parker](https://github.com/parkera)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000368.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0167-swift-encoders/5781)
* Implementation: [apple/swift#9005](https://github.com/apple/swift/pull/9005)
## Introduction
@@ -40,7 +40,7 @@ open class JSONEncoder {
///
/// - parameter value: The value to encode.
/// - returns: A new `Data` value containing the encoded JSON data.
- /// - throws: `CocoaError.coderInvalidValue` if a non-comforming floating-point value is encountered during archiving, and the encoding strategy is `.throw`.
+ /// - throws: `CocoaError.coderInvalidValue` if a non-conforming floating-point value is encountered during archiving, and the encoding strategy is `.throw`.
/// - throws: An error if any value throws an error during encoding.
open func encode(_ value: T) throws -> Data
diff --git a/proposals/0168-multi-line-string-literals.md b/proposals/0168-multi-line-string-literals.md
index dec58cfaed..bf8baa4a2a 100644
--- a/proposals/0168-multi-line-string-literals.md
+++ b/proposals/0168-multi-line-string-literals.md
@@ -1,11 +1,11 @@
# Multi-Line String Literals
* Proposal: [SE-0168](0168-multi-line-string-literals.md)
-* Authors: [John Holdsworth](https://github.com/johnno1962), [Brent Royal-Gordon](https://github.com/brentdax), [Tyler Cloutier](https://github.com/TheArtOfEngineering)
+* Authors: [John Holdsworth](https://github.com/johnno1962), [Becca Royal-Gordon](https://github.com/beccadax), [Tyler Cloutier](https://github.com/TheArtOfEngineering)
* Review Manager: [Joe Groff](https://github.com/jckarter)
-* Status: **Implemented (Swift 4)**
+* Status: **Implemented (Swift 4.0)**
* Implementation: [apple/swift#8813](https://github.com/apple/swift/pull/8813)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035923.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0168-multi-line-string-literals/5715)
* Bugs: [SR-170](https://bugs.swift.org/browse/SR-170), [SR-4701](https://bugs.swift.org/browse/SR-4701), [SR-4708](https://bugs.swift.org/browse/SR-4708), [SR-4874](https://bugs.swift.org/browse/SR-4874)
## Introduction
@@ -15,7 +15,7 @@ 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.
-[Swift-evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html)
+[Swift-evolution thread](https://forums.swift.org/t/multi-line-string-literals/409)
## Motivation
diff --git a/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md b/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
index c9dd5a8be0..043f58d5b6 100644
--- a/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
+++ b/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
@@ -1,10 +1,10 @@
# Improve Interaction Between `private` Declarations and Extensions
* Proposal: [SE-0169](0169-improve-interaction-between-private-declarations-and-extensions.md)
-* Authors: [David Hart](http://github.com/hartbit), [Chris Lattner](https://github.com/lattner)
+* Authors: [David Hart](https://github.com/hartbit), [Chris Lattner](https://github.com/lattner)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0169-improve-interaction-between-private-declarations-and-extensions/5692)
* Previous Revision: [1][Revision 1]
* Bug: [SR-4616](https://bugs.swift.org/browse/SR-4616)
@@ -113,7 +113,7 @@ struct Outer {
In Swift 3 compatibility mode, the compiler will continue to treat `private` as before. In Swift 4 mode, the compiler will modify the semantics of `private` to follow the rules of this proposal. No migration will be necessary as this proposal merely broadens the visibility of `private`.
-Cases where a type had `private` declarations with the same signature in the same type/extension but in different scopes will produce a compiler error in Swift 4. For example, the following piece of code compiles in Swift 3 compatibilty mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode:
+Cases where a type had `private` declarations with the same signature in the same type/extension but in different scopes will produce a compiler error in Swift 4. For example, the following piece of code compiles in Swift 3 compatibility mode but generates a `Invalid redeclaration of 'bar()'` error in Swift 4 mode:
```swift
struct Foo {
@@ -156,6 +156,6 @@ but broader in other ways (allow access across files) would lead to a more
confusing and fractured model.
-[Revision 1]: https://github.com/apple/swift-evolution/blob/e0e04f785dbf5bff138b75e9c47bf94e7db28447/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
+[Revision 1]: https://github.com/swiftlang/swift-evolution/blob/e0e04f785dbf5bff138b75e9c47bf94e7db28447/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
diff --git a/proposals/0170-nsnumber_bridge.md b/proposals/0170-nsnumber_bridge.md
index dd04442751..3dff41e9b7 100644
--- a/proposals/0170-nsnumber_bridge.md
+++ b/proposals/0170-nsnumber_bridge.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0170](0170-nsnumber_bridge.md)
* Author: [Philippe Hausler](https://github.com/phausler)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036226.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0170-nsnumber-bridging-and-numeric-types/5801)
##### Revision history
diff --git a/proposals/0171-reduce-with-inout.md b/proposals/0171-reduce-with-inout.md
index 5a7b48652e..d1ab3d448c 100644
--- a/proposals/0171-reduce-with-inout.md
+++ b/proposals/0171-reduce-with-inout.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0171](0171-reduce-with-inout.md)
* Author: [Chris Eidhof](https://github.com/chriseidhof)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036126.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0171-reduce-with-inout/5769)
## Introduction
@@ -22,7 +22,7 @@ extension Sequence {
}
```
-Swift-evolution thread: [Reduce with inout](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030300.html)
+Swift-evolution thread: [Reduce with inout](https://forums.swift.org/t/reduce-with-inout/4897)
## Motivation
@@ -78,7 +78,7 @@ Without the `inout` parameter, we'd first have to make a `var` copy of the exist
## Source compatibility
-This is purely additive, we don't propose removing the existing `reduce`. Additionaly, because the first argument will have a label `into`, it doesn't add any extra burden to the type checker.
+This is purely additive, we don't propose removing the existing `reduce`. Additionally, because the first argument will have a label `into`, it doesn't add any extra burden to the type checker.
## Effect on ABI stability
@@ -94,4 +94,4 @@ We considered removing the existing `reduce`, but the problem with that is two-f
There has been a really active discussion about the naming of the first parameter. Naming it `mutating:` could deceive people into thinking that the value would get mutated in place. Naming it `mutatingCopyOf:` is also tricky: even though a copy of the struct gets mutated, copying is always implicit when using structs, and it wouldn't copy an instance of a class. `into:` seems the best name so far.
-Under active discussion: the naming of this method. See the [swift-evolution thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030300).
+Under active discussion: the naming of this method. See the [swift-evolution thread](https://forums.swift.org/t/reduce-with-inout/4897).
diff --git a/proposals/0172-one-sided-ranges.md b/proposals/0172-one-sided-ranges.md
index 3a011db27d..0864e86a10 100644
--- a/proposals/0172-one-sided-ranges.md
+++ b/proposals/0172-one-sided-ranges.md
@@ -1,10 +1,10 @@
# One-sided Ranges
* Proposal: [SE-0172](0172-one-sided-ranges.md)
-* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](https://github.com/dabrahams), [Brent Royal-Gordon](https://github.com/brentdax)
+* Authors: [Ben Cohen](https://github.com/airspeedswift), [Dave Abrahams](https://github.com/dabrahams), [Becca Royal-Gordon](https://github.com/beccadax)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036125.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0172-one-sided-ranges/5768)
## Introduction
@@ -64,7 +64,7 @@ variants of `Sequence.enumerated()` when you either want them non-zero-based
i.e. `zip(1..., greeting)`, or want to flip the order i.e. `zip(greeting,
0...)`.
-This syntax would supercede the existing `prefix` and `suffix` operations that
+This syntax would supersede the existing `prefix` and `suffix` operations that
take indices, which will be deprecated in a later release. Note that the
versions that take distances are not covered by this proposal, and would remain.
@@ -171,7 +171,7 @@ extension MutableCollection {
where R.Bound == Index { get set }
}
-extension RangeReplaceableColleciton {
+extension RangeReplaceableCollection {
public mutating func replaceSubrange(
_ subrange: ${Range}, with newElements: C
) where C.Iterator.Element == Iterator.Element, R.Bound == Index
diff --git a/proposals/0173-swap-indices.md b/proposals/0173-swap-indices.md
index f6deb4a050..26055065f5 100644
--- a/proposals/0173-swap-indices.md
+++ b/proposals/0173-swap-indices.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0173](0173-swap-indices.md)
* Author: [Ben Cohen](https://github.com/airspeedswift)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036229.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0173-add-mutablecollection-swapat/5811)
* Implementation: [apple/swift#9119](https://github.com/apple/swift/pull/9119)
## Introduction
@@ -82,7 +82,7 @@ protocol MutableCollection {
The current `swap` is required to `fatalError` on attempts to swap an element
with itself for implementation reasons. This pushes the burden to check this
first onto the caller. While swapping an element with itself is often a logic
-errror (for example, in a `sort` algorithm where you have a fenceposts bug), it
+error (for example, in a `sort` algorithm where you have a fenceposts bug), it
is occasionally a valid situation (for example, it can occur easily in an
implementation of `shuffle`). This implementation removes the precondition.
diff --git a/proposals/0174-filter-range-replaceable.md b/proposals/0174-filter-range-replaceable.md
index 8b89b7db29..ead1768f74 100644
--- a/proposals/0174-filter-range-replaceable.md
+++ b/proposals/0174-filter-range-replaceable.md
@@ -1,22 +1,21 @@
-# Change `filter` to return an associated type
+# Change `RangeReplaceableCollection.filter` to return `Self`
* Proposal: [SE-0174](0174-filter-range-replaceable.md)
* Author: [Ben Cohen](https://github.com/airspeedswift)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Accepted**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000374.html)
+* Status: **Implemented (Swift 4.2)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0174-change-filter-to-return-an-associated-type/5866)
* Bug: [SR-3444](https://bugs.swift.org/browse/SR-3444)
## Introduction
-This proposal changes the `filter` operation on `Sequence` to return an
-associated type, and adds a default implementation to
-`RangeReplaceableCollection` to return the same type as the filtered collection.
+This proposal implements the `filter` operation on `RangeReplaceableCollection`
+to return the same type as the filtered collection.
## Motivation
The recently accepted
-[SE-165](https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md)
+[SE-165](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0165-dict.md)
introduced a version of `filter` on `Dictionary` that returned a
`Dictionary`. This had both performance and usability benefits: in most cases,
a `Dictionary` is what the user wanted from the filter, and creating one
@@ -33,15 +32,9 @@ filter it, you will still get an `Array`.
## Proposed solution
-The existing protocol requirement on `filter` will be changed to return an
-associated type, `Filtered`. The extension providing a default implementation
-will remain as-is, resulting in an inferred value for `Filtered` of
-`[Element]`. `Dictionary` will automatically infer a filtered type of
-`Dictionary` as a result of this change.
-
-A default implementation on `RangeReplaceableCollection` will be provided,
+An implementation of `filter` on `RangeReplaceableCollection` will be provided,
using `init()` and `append(_:)`, so all range-replaceable collections will
-have a `Filtered` of `Self`. Per [SE-163](https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md),
+have a `filter` method returning of `Self`. Per [SE-163](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0163-string-revision-1.md),
this will include `String`.
Note, many sequences (for example, strides or ranges), cannot represent a
@@ -50,33 +43,6 @@ performance problem, `lazy` remains a good solution.
## Detailed design
-Add a `Filtered` associated type to `Sequence`, and change the requirement to
-return it:
-
-```swift
-protocol Sequence {
- associatedtype Filtered
- /// Returns an filtered sequence containing, in order, the elements of the
- /// sequence that satisfy the given predicate.
- ///
- /// In this example, `filter` is used to include only names shorter than
- /// five characters.
- ///
- /// let cast = ["Vivien", "Marlon", "Kim", "Karl"]
- /// let shortNames = cast.filter { $0.characters.count < 5 }
- /// print(shortNames)
- /// // Prints "["Kim", "Karl"]"
- ///
- /// - Parameter isIncluded: A closure that takes an element of the
- /// sequence as its argument and returns a Boolean value indicating
- /// whether the element should be included in the returned sequence.
- /// - Returns: An array of the elements that `includeElement` allowed.
- func filter(
- _ isIncluded: (Iterator.Element) throws -> Bool
- ) rethrows -> Filtered
-}
-```
-
Add a default implementation of `filter` to `RangeReplaceableCollection`
returning `Self`:
@@ -104,7 +70,7 @@ They may be be relying on an array being returned (albeit often in order to
then transform it back into the original type), but this version will still
be available (via the extension on `Sequence`) and will be called if forced
through type context. The only code that will break is if this operation spans
-multple lines:
+multiple lines:
```swift
// filtered used to be [Character], now String
@@ -117,7 +83,7 @@ will only be available in Swift 4.
## Effect on ABI stability
-This change will affect the ABI of `Sequence` and needs to be made before
+This change will affect the ABI of `RangeReplaceableCollection` and needs to be made before
declaring ABI stability.
## Effect on API resilience
@@ -127,10 +93,18 @@ N/A
## Alternatives considered
Status-quo. There are benefits to the consistency of always returning `[Element]`.
+The version on `Sequence` can be reached via type context (`"abc".filter(predicate) as [Element]`).
It could be worthwhile to make a similar change to `map`, but this is beyond
the capabilities of the current generics system because `map` does not preserve
the element type (more specifically, you cannot express a type that is `Self`
-except with a different `Element` in order to provide the default
+except with a different `Element` in order to provide the
implementation on `RangeReplaceableCollection`).
+## History
+
+This proposal originally included a new associated type `Filtered` on `Sequence`. However, this
+was unimplementable due to requiring a recursive type constraint (`Filtered: Sequence`). While
+these were supported in later Swift versions, the additional associated type was not implemented
+and that portion of the proposal has [expired](https://forums.swift.org/t/addressing-unimplemented-evolution-proposals/).
+
diff --git a/proposals/0175-package-manager-revised-dependency-resolution.md b/proposals/0175-package-manager-revised-dependency-resolution.md
index 39816210f2..9dbc7e116f 100644
--- a/proposals/0175-package-manager-revised-dependency-resolution.md
+++ b/proposals/0175-package-manager-revised-dependency-resolution.md
@@ -3,14 +3,14 @@
* Proposal: [SE-0175](0175-package-manager-revised-dependency-resolution.md)
* Author: [Rick Ballard](https://github.com/rballard)
* Review Manager: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036577.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0175-package-manager-revised-dependency-resolution/5896)
## Introduction
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.
## Motivation
-When [SE-0145 Package Manager Version Pinning](https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md) was proposed, it was observed that the proposal was overly complex. In particular, it introduced a configuration option allowing some packages to have autopinning on (the default), while others turned it off; this option affected the behavior of other commands (like `swift package update`, which has a `--repin` flag that does nothing for packages that use autopinning). This configuration option has proved to be unnecessarily confusing.
+When [SE-0145 Package Manager Version Pinning](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md) was proposed, it was observed that the proposal was overly complex. In particular, it introduced a configuration option allowing some packages to have autopinning on (the default), while others turned it off; this option affected the behavior of other commands (like `swift package update`, which has a `--repin` flag that does nothing for packages that use autopinning). This configuration option has proved to be unnecessarily confusing.
In the existing design, when autopinning is on (which is true by default) the `swift package pin` command can't be used to pin packages at specific revisions while allowing other packages to be updated. In particular, if you edit your package's version requirements in the `Package.swift` manifest, there is no way to resolve your package graph to conform to those new requirements without automatically repinning all packages to the latest allowable versions. Thus, specific, intentional pins can not be preserved without turning off autopinning.
@@ -52,7 +52,7 @@ If a dependency is in edit mode, it is allowed to have a different version check
We considered repurposing the existing `fetch` command for this new behavior, instead of renaming the command to `resolve`. However, the name `fetch` is defined by `git` to mean getting the latest content for a repository over the network. Since this package manager command does not always actually fetch new content from the network, it is confusing to use the name `fetch`. In the future, we may offer additional control over when dependency resolution is allowed to perform network access, and we will likely use the word `fetch` in flag names that control that behavior.
-We considered continuing to write out the `Package.pins` file for packages whose [Swift tools version](https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md) was less than 4.0, for maximal compatibility with the Swift 3.1 tools. However, as the old pinning behavior was a workflow feature and not a fundamental piece of package compatibility, we do not consider it necessary to support in the 4.0 tools.
+We considered continuing to write out the `Package.pins` file for packages whose [Swift tools version](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md) was less than 4.0, for maximal compatibility with the Swift 3.1 tools. However, as the old pinning behavior was a workflow feature and not a fundamental piece of package compatibility, we do not consider it necessary to support in the 4.0 tools.
We considered keeping the `pin` and `unpin` commands, with the new behavior as discussed briefly in this proposal. While we think we may wish to bring this feature back in the future, we do not consider it critical for this release; the workflow it supports (updating all packages except a handful which have been pinned) is not something most users will need, and there are workarounds (e.g. specify an explicit dependency in the `Package.swift` manifest).
diff --git a/proposals/0176-enforce-exclusive-access-to-memory.md b/proposals/0176-enforce-exclusive-access-to-memory.md
index 0680ccb258..f11512ff96 100644
--- a/proposals/0176-enforce-exclusive-access-to-memory.md
+++ b/proposals/0176-enforce-exclusive-access-to-memory.md
@@ -3,9 +3,9 @@
* Proposal: [SE-0176](0176-enforce-exclusive-access-to-memory.md)
* Author: [John McCall](https://github.com/rjmccall)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Implemented (Swift 4)**
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/7e6816c22a29b0ba9bdf63ff92b380f9e963860a/proposals/0176-enforce-exclusive-access-to-memory.md)
-* Previous Discussion: [Email Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036308.html)
+* Status: **Implemented (Swift 4.0)**
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/7e6816c22a29b0ba9bdf63ff92b380f9e963860a/proposals/0176-enforce-exclusive-access-to-memory.md)
+* Previous Discussion: [Email Thread](https://forums.swift.org/t/review-se-0176-enforce-exclusive-access-to-memory/5836)
## Introduction
@@ -479,7 +479,7 @@ In the short term, these problems can be worked around with
``withUnsafeMutableBufferPointer``.
We do know that swapping two array elements will be problematic,
-and accordingly we are (separately proposing)[https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md] to add a
+and accordingly we are (separately proposing)[https://github.com/swiftlang/swift-evolution/blob/master/proposals/0173-swap-indices.md] to add a
``swapAt`` method to ``MutableCollection`` that takes two indices
rather than two ``inout`` arguments. The Swift 3 compatibility
mode should recognize the swap-of-elements pattern and automatically
@@ -740,7 +740,7 @@ automatically to avoid source-compatibility problems.
## Effect on ABI stability and resilience
-In order to gain the performance and language-desing benefits of
+In order to gain the performance and language-design benefits of
exclusivity, we must be able to assume that it is followed faithfully
in various places throughout the ABI. Therefore, exclusivity must be
enforced before we commit to a stable ABI, or else we'll be stuck with
diff --git a/proposals/0177-add-clamped-to-method.md b/proposals/0177-add-clamped-to-method.md
index 89639aa910..37d3dfafc3 100644
--- a/proposals/0177-add-clamped-to-method.md
+++ b/proposals/0177-add-clamped-to-method.md
@@ -10,7 +10,7 @@
This proposal aims to add functionality to the standard library for clamping a value to a provided `Range`.
The proposed function would allow the user to specify a range to clamp a value to where if the value fell within the range, the value would be returned as is, if the value being clamped exceeded the upper or lower bound then the upper or lower bound would be returned respectively.
-Swift-evolution thread: [Add a `clamp` function to Algorithm.swift](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/thread.html#33674)
+Swift-evolution thread: [Add a `clamp` function to Algorithm.swift](https://forums.swift.org/t/add-a-clamp-function-to-algorithm-swift/5405)
## Motivation
diff --git a/proposals/0178-character-unicode-view.md b/proposals/0178-character-unicode-view.md
index 2dc8a59361..64264a6e97 100644
--- a/proposals/0178-character-unicode-view.md
+++ b/proposals/0178-character-unicode-view.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0178](0178-character-unicode-view.md)
* Author: [Ben Cohen](https://github.com/airspeedswift)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170515/036714.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0178-add-unicodescalars-property-to-character/5941)
* Implementation: [apple/swift#9675](https://github.com/apple/swift/pull/9675)
## Introduction
diff --git a/proposals/0179-swift-run-command.md b/proposals/0179-swift-run-command.md
index 728efbe82b..f43b30b473 100644
--- a/proposals/0179-swift-run-command.md
+++ b/proposals/0179-swift-run-command.md
@@ -1,10 +1,10 @@
# Swift `run` Command
* Proposal: [SE-0179](0179-swift-run-command.md)
-* Author: [David Hart](http://github.com/hartbit/)
+* Author: [David Hart](https://github.com/hartbit/)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036909.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-revision-se-0179-swift-run-command/6031)
* Implementation: [apple/swift-package-manager#1187](https://github.com/apple/swift-package-manager/pull/1187)
## Introduction
diff --git a/proposals/0180-string-index-overhaul.md b/proposals/0180-string-index-overhaul.md
index db80a39fbe..abe8de6074 100644
--- a/proposals/0180-string-index-overhaul.md
+++ b/proposals/0180-string-index-overhaul.md
@@ -3,10 +3,10 @@
* Proposal: [SE-0180](0180-string-index-overhaul.md)
* Author: [Dave Abrahams](https://github.com/dabrahams)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037942.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0180-string-index-overhaul/6286)
* Implementation: [apple/swift#9806](https://github.com/apple/swift/pull/9806)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/72b8d90becd60b7cc7695607ae908ef251f1e966/proposals/0180-string-index-overhaul.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/72b8d90becd60b7cc7695607ae908ef251f1e966/proposals/0180-string-index-overhaul.md)
## Introduction
@@ -18,7 +18,7 @@ and exposes a public `encodedOffset` property and initializer that can
be used to serialize and deserialize positions in a `String` or
`Substring`.
-Swift-evolution thread: [Pitch: String Index Overhaul](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036874.html)
+Swift-evolution thread: [Pitch: String Index Overhaul](https://forums.swift.org/t/pitch-string-index-overhaul/6017)
## Motivation
@@ -129,7 +129,7 @@ let tagEnd = html.utf16[tagStart...].index(of: close)
let tag = html[tagStart...tagEnd]
```
-A property and an intializer will be added to `String.Index`, exposing
+A property and an initializer will be added to `String.Index`, exposing
the offset of the index in code units (currently only UTF-16) from the
beginning of the string:
diff --git a/proposals/0181-package-manager-cpp-language-version.md b/proposals/0181-package-manager-cpp-language-version.md
index 7389edd4bb..5fd52c8f02 100644
--- a/proposals/0181-package-manager-cpp-language-version.md
+++ b/proposals/0181-package-manager-cpp-language-version.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0181](0181-package-manager-cpp-language-version.md)
* Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
* Review Manager: [Daniel Dunbar](https://github.com/ddunbar)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170717/038142.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-revision-se-0181-package-manager-c-c-language-standard-support/6353)
* Implementation: [apple/swift-package-manager#1264](https://github.com/apple/swift-package-manager/pull/1264)
## Introduction
diff --git a/proposals/0182-newline-escape-in-strings.md b/proposals/0182-newline-escape-in-strings.md
index 866ac8ff60..6f3cfb9fc9 100644
--- a/proposals/0182-newline-escape-in-strings.md
+++ b/proposals/0182-newline-escape-in-strings.md
@@ -3,16 +3,16 @@
* Proposal: [SE-0182](0182-newline-escape-in-strings.md)
* Authors: [John Holdsworth](https://github.com/johnno1962), [David Hart](https://github.com/hartbit), [Adrian Zubarev](https://github.com/DevAndArtist)
* Review Manager: [Chris Lattner](https://github.com/lattner)
-* Status: **Implemented (Swift 4)**
+* Status: **Implemented (Swift 4.0)**
* Implementation: [apple/swift#11080](https://github.com/apple/swift/pull/11080)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000393.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0182-string-newline-escaping/6355)
* Previous Proposal: [SE-0168](0168-multi-line-string-literals.md)
## Introduction
This proposal is a refinement of [SE-0168](0168-multi-line-string-literals.md) 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.
-Swift-evolution thread: [Discussion thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035923.html)
+Swift-evolution thread: [Discussion thread](https://forums.swift.org/t/accepted-se-0168-multi-line-string-literals/5715)
## Motivation
diff --git a/proposals/0183-substring-affordances.md b/proposals/0183-substring-affordances.md
index 7e0ddae817..eb83064787 100644
--- a/proposals/0183-substring-affordances.md
+++ b/proposals/0183-substring-affordances.md
@@ -3,8 +3,8 @@
* Proposal: [SE-0183](0183-substring-affordances.md)
* Author: [Ben Cohen](https://github.com/airspeedswift)
* Review Manager: [Chris Lattner](https://github.com/lattner)
-* Status: **Implemented (Swift 4)**
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000395.html)
+* Status: **Implemented (Swift 4.0)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0183-substring-performance-affordances/6393)
* Bug: [SR-4933](https://bugs.swift.org/browse/SR-4933)
## Introduction
@@ -74,7 +74,7 @@ case of `filter`).
## Effect on ABI stability
-The switch from conrete to generic types needs to be made before ABI stability.
+The switch from concrete to generic types needs to be made before ABI stability.
## Alternatives considered
diff --git a/proposals/0184-unsafe-pointers-add-missing.md b/proposals/0184-unsafe-pointers-add-missing.md
index 38a2e9e4f3..a8cff99c6b 100644
--- a/proposals/0184-unsafe-pointers-add-missing.md
+++ b/proposals/0184-unsafe-pointers-add-missing.md
@@ -1,22 +1,22 @@
# Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size
* Proposal: [SE-0184](0184-unsafe-pointers-add-missing.md)
-* Author: [Kelvin Ma (“Taylor Swift”)](https://github.com/kelvin13)
+* Author: [Diana Ma (“Taylor Swift”)](https://github.com/tayloraswift)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#12200](https://github.com/apple/swift/pull/12200)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040248.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-revisions-se-0184-unsafe-mutable-raw-buffer-pointer-add-missing-methods-adjust-existing-labels-for-clarity-and-remove-deallocation-size/6772)
## Introduction
-*This document is a spin-off from a much larger [original proposal](https://github.com/kelvin13/swift-evolution/blob/e888af466c9993de977f6999a131eadd33291b06/proposals/0184-unsafe-pointers-add-missing.md), 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 document is a spin-off from a much larger [original proposal](https://github.com/tayloraswift/swift-evolution/blob/e888af466c9993de977f6999a131eadd33291b06/proposals/0184-unsafe-pointers-add-missing.md), 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.*
Swift’s pointer types are an important interface for low-level memory manipulation, but the current API design is not very consistent, complete, or convenient. In some places, poor naming choices and overengineered function signatures compromise memory safety by leading users to believe that they have allocated or freed memory when in fact, they have not. This proposal seeks to improve the Swift pointer API by ironing out naming inconsistencies, adding missing methods, and reducing excessive verbosity, offering a more convenient, more sensible, and less bug-prone API.
-Swift-evolution threads: [Pitch: Improved Swift pointers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038013.html), [Pitch: More Improved Swift pointers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170717/038121.html)
+Swift-evolution threads: [Pitch: Improved Swift pointers](https://forums.swift.org/t/pitch-improved-swift-pointers/6318), [Pitch: More Improved Swift pointers](https://forums.swift.org/t/pitch-improved-swift-pointers/6318)
-Implementation branch: [`kelvin13:se-0184a`](https://github.com/kelvin13/swift/tree/se-0184a)
+Implementation branch: [`tayloraswift:se-0184a`](https://github.com/tayloraswift/swift/tree/se-0184a)
## Background
diff --git a/proposals/0185-synthesize-equatable-hashable.md b/proposals/0185-synthesize-equatable-hashable.md
index b2e13814bc..40a20d97d8 100644
--- a/proposals/0185-synthesize-equatable-hashable.md
+++ b/proposals/0185-synthesize-equatable-hashable.md
@@ -5,7 +5,7 @@
* Review Manager: [Chris Lattner](https://github.com/lattner)
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#9619](https://github.com/apple/swift/pull/9619)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-August/000400.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0185-synthesizing-equatable-and-hashable-conformance/6493)
## Introduction
@@ -16,7 +16,7 @@ the compiler to automatically synthesize conformance to `Equatable` and
the correct implementation is known to be possible.
Swift-evolution thread: [Universal Equatability, Hashability, and Comparability
-](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012099.html)
+](https://forums.swift.org/t/universal-equatability-hashability-and-comparability/1718)
## Motivation
diff --git a/proposals/0186-remove-ownership-keyword-support-in-protocols.md b/proposals/0186-remove-ownership-keyword-support-in-protocols.md
index 3ec72f9d9e..7ec3fa0194 100644
--- a/proposals/0186-remove-ownership-keyword-support-in-protocols.md
+++ b/proposals/0186-remove-ownership-keyword-support-in-protocols.md
@@ -5,15 +5,15 @@
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#11744](https://github.com/apple/swift/pull/11744)
-* [Review thread on swift-evolution](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039863.html)
+* [Review thread on swift-evolution](https://forums.swift.org/t/se-0186-remove-ownership-keyword-support-in-protocols/6678)
* Bug: [SR-479](https://bugs.swift.org/browse/SR-479)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170925/040012.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0186-remove-ownership-keyword-support-in-protocols/6736)
## Introduction
This proposal removes support for the keywords `weak` and `unowned` for property declarations in a protocol.
-Swift-evolution thread: [Ownership on protocol property requirements](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036495.html) thread.
+Swift-evolution thread: [Ownership on protocol property requirements](https://forums.swift.org/t/ownership-on-protocol-property-requirements/5872) thread.
## Motivation
diff --git a/proposals/0187-introduce-filtermap.md b/proposals/0187-introduce-filtermap.md
index c7e03ba0cf..a03909edc1 100644
--- a/proposals/0187-introduce-filtermap.md
+++ b/proposals/0187-introduce-filtermap.md
@@ -6,11 +6,11 @@
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#12819](https://github.com/apple/swift/pull/12819)
* Decision Notes:
- [Review #0](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040609.html),
- [Review #1](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040999.html),
- [Review #2](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041342.html),
- [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042207.html)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/2d24b0ce9f138858b8341467170d6d8ba973827f/proposals/0187-introduce-filtermap.md)
+ [Review #0](https://forums.swift.org/t/draft-introduce-sequence-filteredmap/6872),
+ [Review #1](https://forums.swift.org/t/review-se-0187-introduce-sequence-filtermap/6977),
+ [Review #2](https://forums.swift.org/t/accepted-and-focused-re-review-se-0187-introduce-sequence-filtermap/7076),
+ [Rationale](https://forums.swift.org/t/accepted-with-revisions-se-0187-introduce-sequence-filtermap/7290)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/2d24b0ce9f138858b8341467170d6d8ba973827f/proposals/0187-introduce-filtermap.md)
## Introduction
diff --git a/proposals/0188-stdlib-index-types-hashable.md b/proposals/0188-stdlib-index-types-hashable.md
index d732d86297..a1e2c5a83c 100644
--- a/proposals/0188-stdlib-index-types-hashable.md
+++ b/proposals/0188-stdlib-index-types-hashable.md
@@ -10,7 +10,7 @@
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.
-Swift-evolution "thread:" [[draft] Make Standard Library Index Types Hashable](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040908.html)
+Swift-evolution "thread:" [[draft] Make Standard Library Index Types Hashable](https://forums.swift.org/t/draft-make-standard-library-index-types-hashable/6946)
## Motivation
@@ -28,7 +28,7 @@ let firstChar = \String.[string.startIndex]
## Proposed solution
-This proposal would add `Hashable` conformance to all the index types in the standard library. With that done, `[Int]`, `String`, and all other standard libary collections would have the same behavior when using subscripts in key paths.
+This proposal would add `Hashable` conformance to all the index types in the standard library. With that done, `[Int]`, `String`, and all other standard library collections would have the same behavior when using subscripts in key paths.
## Detailed design
diff --git a/proposals/0189-restrict-cross-module-struct-initializers.md b/proposals/0189-restrict-cross-module-struct-initializers.md
index dcf935f60c..a587ec18c4 100644
--- a/proposals/0189-restrict-cross-module-struct-initializers.md
+++ b/proposals/0189-restrict-cross-module-struct-initializers.md
@@ -5,18 +5,9 @@
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#12834](https://github.com/apple/swift/pull/12834)
-* Pre-review discussion: [Restrict Cross-module Struct Initializers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040261.html)
-* [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171120/041478.html)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041801.html)
-
-
+* Pre-review discussion: [Restrict Cross-module Struct Initializers](https://forums.swift.org/t/pitch-restrict-cross-module-struct-initializers/6780)
+* [Swift Evolution Review Thread](https://forums.swift.org/t/review-se-0189-restrict-cross-module-struct-initializers/7066)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0189-restrict-cross-module-struct-initializers/7164)
## Introduction
diff --git a/proposals/0190-target-environment-platform-condition.md b/proposals/0190-target-environment-platform-condition.md
index 757c06c034..8de170fe27 100644
--- a/proposals/0190-target-environment-platform-condition.md
+++ b/proposals/0190-target-environment-platform-condition.md
@@ -4,9 +4,9 @@
* Authors: [Erica Sadun](https://github.com/erica), [Graydon Hoare](https://github.com/graydon)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Status: **Implemented (Swift 4.1)**
-* [Swift Evolution Review Thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041695.html)
+* [Swift Evolution Review Thread](https://forums.swift.org/t/review-se-0190-target-environment-platform-condition/7082)
* Implementation: [apple/swift#12964](https://github.com/apple/swift/pull/12964)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041741.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0190-target-environment-platform-condition/7138)
## Introduction
@@ -16,8 +16,8 @@ AVFoundation Camera code.
Swift-evolution threads:
-* [Expanding Build Configuration Tests for Simulator and Device targets](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012557.html)
-* [Target environment platform condition](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040652.html)
+* [Expanding Build Configuration Tests for Simulator and Device targets](https://forums.swift.org/t/draft-expanding-build-configuration-tests-for-simulator-and-device-targets/1793)
+* [Target environment platform condition](https://forums.swift.org/t/draft-target-environment-platform-condition/6884)
## Motivation
diff --git a/proposals/0191-eliminate-indexdistance.md b/proposals/0191-eliminate-indexdistance.md
index d03b54e62b..73a23ed9d8 100644
--- a/proposals/0191-eliminate-indexdistance.md
+++ b/proposals/0191-eliminate-indexdistance.md
@@ -5,7 +5,7 @@
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Implemented (Swift 4.1)**
* Implementation: [apple/swift#12641](https://github.com/apple/swift/pull/12641)
-* Decision Notes: [Rationale](https://lists.swift.org/pipermail/swift-evolution-announce/2017-December/000415.html)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0191-eliminate-indexdistance-from-collection/7191)
## Introduction
@@ -17,8 +17,8 @@ Eliminate the associated type `IndexDistance` from `Collection`, and modify all
an `Int`, generic algorithms on `Collection` need to either constrain `IndexDistance == Int` or write their algorithm to be generic over any `SignedInteger`.
Swift 4.0 introduced the ability to constrain associated types with `where` clauses
-([SE-142](https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md)) and will soon allow protocol constraints
-to be recursive ([SE-157](https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md)). With these features,
+([SE-142](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md)) and will soon allow protocol constraints
+to be recursive ([SE-157](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md)). With these features,
writing generic algorithms against `Collection` is finally a realistic tool for intermediate Swift programmers. You no longer need to know to
constrain `SubSequence.Element == Element` or `SubSequence: Collection`, missing constraints that previously led to inexplicable error messages.
diff --git a/proposals/0192-non-exhaustive-enums.md b/proposals/0192-non-exhaustive-enums.md
index f5627eafa2..534cef4c91 100644
--- a/proposals/0192-non-exhaustive-enums.md
+++ b/proposals/0192-non-exhaustive-enums.md
@@ -3,21 +3,13 @@
* Proposal: [SE-0192](0192-non-exhaustive-enums.md)
* Author: [Jordan Rose](https://github.com/jrose-apple)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Implemented (Swift 5)**
+* Status: **Implemented (Swift 5.0)**
* Implementation: [apple/swift#14945](https://github.com/apple/swift/pull/14945)
-* Previous revision: [1](https://github.com/apple/swift-evolution/blob/a773d07ff4beab8b7855adf0ac56d1e13bb7b44c/proposals/0192-non-exhaustive-enums.md), [2 (informal)](https://github.com/jrose-apple/swift-evolution/blob/57dfa2408fe210ed1d5a1251f331045b988ee2f0/proposals/0192-non-exhaustive-enums.md), [3](https://github.com/apple/swift-evolution/blob/af284b519443d3d985f77cc366005ea908e2af59/proposals/0192-non-exhaustive-enums.md)
-* Pre-review discussion: [Enums and Source Compatibility](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038663.html), with additional [orphaned thread](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039787.html)
-* Review discussion: [Review author summarizes some feedback from review discussion and proposes alternatives](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180101/042480.html), [full discussion thread](https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291/337), plus [Handling unknown cases in enums](https://forums.swift.org/t/handling-unknown-cases-in-enums-re-se-0192/7388/)
+* Previous revision: [1](https://github.com/swiftlang/swift-evolution/blob/a773d07ff4beab8b7855adf0ac56d1e13bb7b44c/proposals/0192-non-exhaustive-enums.md), [2 (informal)](https://github.com/jrose-swiftlang/swift-evolution/blob/57dfa2408fe210ed1d5a1251f331045b988ee2f0/proposals/0192-non-exhaustive-enums.md), [3](https://github.com/swiftlang/swift-evolution/blob/af284b519443d3d985f77cc366005ea908e2af59/proposals/0192-non-exhaustive-enums.md)
+* Pre-review discussion: [Enums and Source Compatibility](https://forums.swift.org/t/enums-and-source-compatibility/6460), with additional [orphaned thread](https://forums.swift.org/t/enums-and-source-compatibility/6651)
+* Review discussion: [Review author summarizes some feedback from review discussion and proposes alternatives](https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291/26), [full discussion thread](https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291/337), plus [Handling unknown cases in enums](https://forums.swift.org/t/handling-unknown-cases-in-enums-re-se-0192/7388/)
* Decision Notes: [Rationale](https://forums.swift.org/t/se-0192-non-exhaustive-enums-review-2/11043/62)
-
-
## Introduction
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.
@@ -468,7 +460,7 @@ I didn't have a strong preference for any particular choice as long as it *isn't
Note that "nonextensible" does have one problem: Apple already uses [`NS_TYPED_EXTENSIBLE_ENUM `][NS_TYPED_EXTENSIBLE_ENUM] to refer to enum-like sets of constants (usually strings) that *clients* can add "cases" to. That's not the same meaning as the exhaustiveness discussed in this proposal.
-During the first review for this proposal, Brent Royal-Gordon suggested "frozen", which was met with general approval or at least no major objections.
+During the first review for this proposal, Becca Royal-Gordon suggested "frozen", which was met with general approval or at least no major objections.
[NS_TYPED_EXTENSIBLE_ENUM]: https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-ID206
@@ -538,7 +530,7 @@ unknown:
### Testing invalid cases
-Another issue with non-frozen enums is that clients cannot properly test what happens when a new case is introduced, almost by definition. Brent Royal-Gordon came up with the idea to have a new type annotation that would allow the creation of an invalid enum value. Since this is only something to use for testing, the initial version of the idea used `@testable` as the spelling for the annotation. The tests could then use a special expression, `#invalid`, to pass this invalid value to a function with a `@testable` enum parameter.
+Another issue with non-frozen enums is that clients cannot properly test what happens when a new case is introduced, almost by definition. Becca Royal-Gordon came up with the idea to have a new type annotation that would allow the creation of an invalid enum value. Since this is only something to use for testing, the initial version of the idea used `@testable` as the spelling for the annotation. The tests could then use a special expression, `#invalid`, to pass this invalid value to a function with a `@testable` enum parameter.
However, this would only work in cases where the action to be taken does not actually depend on the enum value. If it needs to be passed to the original library that owns the enum, or used with an API that is not does not have this annotation, the code still cannot be tested properly.
@@ -569,7 +561,7 @@ The core team decided that this feature was not worth the disruption and long-te
The [initial version][] of this proposal did not include `@unknown`, and required people to use a normal `default` to handle cases added in the future instead. However, many people were unhappy with the loss of exhaustivity checking for `switch` statements, both for enums in libraries distributed as source and enums imported from Apple's SDKs. While this is an additive feature that does not affect ABI, it seems to be one that the community considers a necessary part of a language model that provides non-frozen enums.
- [initial version]: https://github.com/apple/swift-evolution/blob/a773d07ff4beab8b7855adf0ac56d1e13bb7b44c/proposals/0192-non-exhaustive-enums.md
+ [initial version]: https://github.com/swiftlang/swift-evolution/blob/a773d07ff4beab8b7855adf0ac56d1e13bb7b44c/proposals/0192-non-exhaustive-enums.md
### Mixing `@unknown` with other catch-all cases
diff --git a/proposals/0193-cross-module-inlining-and-specialization.md b/proposals/0193-cross-module-inlining-and-specialization.md
index 7daee5b463..bbdcc7305a 100644
--- a/proposals/0193-cross-module-inlining-and-specialization.md
+++ b/proposals/0193-cross-module-inlining-and-specialization.md
@@ -75,7 +75,7 @@ The attribute cannot be applied to local declarations, that is, declarations nes
When applied to a subscript or computed property, the attribute applies to both the getter and setter.
-Note that only delegating initializers (those that assign to `self` or call another initializer via `self.init`) can be inlinable. Root initializers which initialize the stored properties of a struct or class directly cannot be inlinable. For motivation, see [SE-0189 Restrict Cross-module Struct Initializers](https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md).
+Note that only delegating initializers (those that assign to `self` or call another initializer via `self.init`) can be inlinable. Root initializers which initialize the stored properties of a struct or class directly cannot be inlinable. For motivation, see [SE-0189 Restrict Cross-module Struct Initializers](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md).
### Inlinable contexts
@@ -171,7 +171,7 @@ The closest analogue in C to `@usableFromInline` is a non-`static` function that
## Alternatives considered
-One possible alterative would be to add a new compiler mode where _all_ declarations become implicitly `@inlinable`, and _all_ private and internal declarations become `@usableFromInline`.
+One possible alternative would be to add a new compiler mode where _all_ declarations become implicitly `@inlinable`, and _all_ private and internal declarations become `@usableFromInline`.
However, such a compilation mode would not solve the problem of delivering a stable ABI and standard library which can be deployed separately from user code. We _don't want_ all declaration bodies in the standard library to be available to the optimizer when building user code.
diff --git a/proposals/0194-derived-collection-of-enum-cases.md b/proposals/0194-derived-collection-of-enum-cases.md
index 8b9d27a002..ee60a8d2fb 100644
--- a/proposals/0194-derived-collection-of-enum-cases.md
+++ b/proposals/0194-derived-collection-of-enum-cases.md
@@ -1,7 +1,7 @@
# Derived Collection of Enum Cases
* Proposal: [SE-0194](0194-derived-collection-of-enum-cases.md)
-* Authors: [Jacob Bandes-Storch](https://github.com/jtbandes), [Brent Royal-Gordon](https://github.com/brentdax), [Robert Widmann](https://github.com/CodaFi)
+* Authors: [Jacob Bandes-Storch](https://github.com/jtbandes), [Becca Royal-Gordon](https://github.com/beccadax), [Robert Widmann](https://github.com/CodaFi)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Review Thread: [SE-0194 review][se8]
* Status: **Implemented (Swift 4.2)**
diff --git a/proposals/0195-dynamic-member-lookup.md b/proposals/0195-dynamic-member-lookup.md
index 3541b01560..3989a15b50 100644
--- a/proposals/0195-dynamic-member-lookup.md
+++ b/proposals/0195-dynamic-member-lookup.md
@@ -4,7 +4,7 @@
* Author: [Chris Lattner](https://github.com/lattner)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Implementation: [apple/swift#14546](https://github.com/apple/swift/pull/14546)
-* [Previous Revision #1](https://github.com/apple/swift-evolution/commit/59c7455170c231f3df9ab0ba923262e126afaa06#diff-b3460d13f154c3d6b1d8396e4159a1d2)
+* [Previous Revision #1](https://github.com/swiftlang/swift-evolution/commit/59c7455170c231f3df9ab0ba923262e126afaa06#diff-b3460d13f154c3d6b1d8396e4159a1d2)
* Status: **Implemented (Swift 4.2)**
* Decision Notes: [Review extended](https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/126), [Rationale](https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/160)
@@ -160,7 +160,7 @@ the code would have explicit member lookups all over the place:
If you'd like to explore what Python interoperability looks like with plain Swift 4 (i.e. without
either of these proposals) then check out the [Xcode 9 playground demonstrating Python
-interoperability](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042029.html)
+interoperability](https://forums.swift.org/t/python-interop-with-swift-4/7109/9)
that has been periodically posted to swift-evolution over the last few months.
While this is a syntactic sugar proposal, we believe that this expands Swift to be usable in
@@ -200,7 +200,7 @@ see the JSON example below).
## Example Usage
While there are many potential uses of this sort of API, one motivating example comes from a
-[prototype Python interoperability layer](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042029.html).
+[prototype Python interoperability layer](https://forums.swift.org/t/python-interop-with-swift-4/7109/9).
There are many ways to implement this, and the details are not
particularly important, but it is perhaps useful to know that this is directly useful to address
the motivation section described above. Given a currency type of `PyVal`, an implementation
@@ -644,12 +644,12 @@ someday have fast compile times).
### Introduce a language independent "foreign class" feature to Swift
-One suggestion was to introduce a [general "foreign class" feature to Swift](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042227.html). The core team met to discuss this and concluded that it was the wrong direction to go. Among opinions held by core team members, several believed that forcing other languages models into the Swift model would violate their fundamental principles (e.g. Go and Javascript don't *have* classes), some felt it would be too invasive into the compiler, and others believed that such an approach ends up requiring a `DynamicMemberLookup` related feature anyway - because
+One suggestion was to introduce a [general "foreign class" feature to Swift](https://forums.swift.org/t/proposal-introduce-user-defined-dynamic-member-lookup-types/7129/90). The core team met to discuss this and concluded that it was the wrong direction to go. Among opinions held by core team members, several believed that forcing other languages models into the Swift model would violate their fundamental principles (e.g. Go and Javascript don't *have* classes), some felt it would be too invasive into the compiler, and others believed that such an approach ends up requiring a `DynamicMemberLookup` related feature anyway - because
e.g. Python doesn't require property declarations.
### Use "automatically generated wrappers" to interface with Python
-This approach has [numerous problems](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180101/042522.html). Beyond that, wrappers also fundamentally require that we take (something like) this proposal
+This approach has [numerous problems](https://forums.swift.org/t/dynamicmemberlookup-proposal-status-update/7358). Beyond that, wrappers also fundamentally require that we take (something like) this proposal
to work in the first place. The primary issue is that Python (and other dynamic languages)
require no property declarations. If you have no property declaration, there is nothing for the
wrapper generator to [w]rap or generate.
diff --git a/proposals/0196-diagnostic-directives.md b/proposals/0196-diagnostic-directives.md
index 9d6a940864..2b69a98991 100644
--- a/proposals/0196-diagnostic-directives.md
+++ b/proposals/0196-diagnostic-directives.md
@@ -4,7 +4,7 @@
* Author: [Harlan Haskins](https://github.com/harlanhaskins)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Implementation: [apple/swift#14048](https://github.com/apple/swift/pull/14048)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/ab0c22a2340be9bfcb82e6f237752b4d959a93b7/proposals/0196-diagnostic-directives.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/ab0c22a2340be9bfcb82e6f237752b4d959a93b7/proposals/0196-diagnostic-directives.md)
* Status: **Implemented (Swift 4.2)**
## Introduction
@@ -152,10 +152,10 @@ to this proposal, and both could be addressed in future proposals.
# Rationale
On February 1, 2018 the Core Team decided to **accept** this proposal with
-slight revision over the [original proposal](https://github.com/apple/swift-evolution/blob/ab0c22a2340be9bfcb82e6f237752b4d959a93b7/proposals/0196-diagnostic-directives.md).
+slight revision over the [original proposal](https://github.com/swiftlang/swift-evolution/blob/ab0c22a2340be9bfcb82e6f237752b4d959a93b7/proposals/0196-diagnostic-directives.md).
The only revision over the original proposal is to change the syntax to use
-`#warning()` instead of `#warning `. This fits well with
+`#warning()` instead of `#warning `. This fits well with
most of Swift's existing compiler directives, and was strongly supported in
the [review discussion](https://forums.swift.org/t/se-0196-compiler-diagnostic-directives/8734).
diff --git a/proposals/0197-remove-where.md b/proposals/0197-remove-where.md
index e74c332e92..514aabc2cf 100644
--- a/proposals/0197-remove-where.md
+++ b/proposals/0197-remove-where.md
@@ -6,7 +6,7 @@
* Status: **Implemented (Swift 4.2)**
* Implementation: [apple/swift#11576](https://github.com/apple/swift/pull/11576)
* Review: [Thread](https://forums.swift.org/t/se-0197-add-in-place-remove-where/8872)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/feec7890d6c193e9260ac9905456f25ef5656acd/proposals/0197-remove-where.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/feec7890d6c193e9260ac9905456f25ef5656acd/proposals/0197-remove-where.md)
## Introduction
diff --git a/proposals/0198-playground-quicklook-api-revamp.md b/proposals/0198-playground-quicklook-api-revamp.md
index 962e6aef4c..7b6608d542 100644
--- a/proposals/0198-playground-quicklook-api-revamp.md
+++ b/proposals/0198-playground-quicklook-api-revamp.md
@@ -7,15 +7,6 @@
* Review thread: [SE-0198 review](https://forums.swift.org/t/se-0198-playground-quicklook-api-revamp/9448/16)
* Status: **Implemented (Swift 4.1)**
-
-
## Introduction ##
The standard library currently includes API which allows a type to customize its
@@ -47,7 +38,7 @@ alternate object or value (as an `Any`) which would serve as their
description. The PlaygroundLogger framework, also part of
swift-xcode-playground-support, will be updated to understand this protocol.
-Swift-evolution thread: [Discussion thread topic for that proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042639.html)
+Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/proposal-revamp-the-playground-quicklook-apis/7392)
## Motivation ##
@@ -270,7 +261,7 @@ support the replacement of `CustomPlaygroundQuickLookable` with
`CustomPlaygroundDisplayConvertible`. Instead, we intend for Swift 4.1 to be a
deprecation period for these APIs, allowing any code bases which implement
`CustomPlaygroundQuickLookable` to manually switch to the new protocol. While
-this migration may not be trivial programatically, it should -- in most cases --
+this migration may not be trivial programmatically, it should -- in most cases --
be fairly trivial for someone to hand-migrate to
`CustomPlaygroundDisplayConvertible`. During the deprecation period, the
PlaygroundLogger framework will continue to honor implementations of
diff --git a/proposals/0199-bool-toggle.md b/proposals/0199-bool-toggle.md
index d289733c68..b9a4c22384 100644
--- a/proposals/0199-bool-toggle.md
+++ b/proposals/0199-bool-toggle.md
@@ -1,7 +1,7 @@
# Adding `toggle` to `Bool`
* Proposal: [SE-0199](0199-bool-toggle.md)
-* Author: [Chris Eidhof](http://chris.eidhof.nl)
+* Author: [Chris Eidhof](https://github.com/chriseidhof)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift/)
* Status: **Implemented (Swift 4.2)**
* Decision notes: [Rationale](https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681)
@@ -13,7 +13,7 @@
I propose adding a `mutating func toggle` to `Bool`. It toggles the `Bool`.
-- Swift-evolution thread: [Discussion thread topic for that proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042767.html)
+- Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/adding-toggle-to-bool/7414)
- Swift forums thread: [pitch: adding toggle to Bool](https://forums.swift.org/t/pitch-adding-toggle-to-bool/7414)
## Motivation
diff --git a/proposals/0200-raw-string-escaping.md b/proposals/0200-raw-string-escaping.md
index 422addb28f..b08508ca0c 100644
--- a/proposals/0200-raw-string-escaping.md
+++ b/proposals/0200-raw-string-escaping.md
@@ -1,10 +1,10 @@
# Enhancing String Literals Delimiters to Support Raw Text
* Proposal: [SE-0200](0200-raw-string-escaping.md)
-* Authors: [John Holdsworth](https://github.com/johnno1962), [Brent Royal-Gordon](https://github.com/brentdax), [Erica Sadun](https://github.com/erica)
+* Authors: [John Holdsworth](https://github.com/johnno1962), [Becca Royal-Gordon](https://github.com/beccadax), [Erica Sadun](https://github.com/erica)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/102b2f2770f0dab29f254a254063847388647a4a/proposals/0200-raw-string-escaping.md)
-* Status: **Implemented (Swift 5)**
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/102b2f2770f0dab29f254a254063847388647a4a/proposals/0200-raw-string-escaping.md)
+* Status: **Implemented (Swift 5.0)**
* Implementation: [apple/swift#17668](https://github.com/apple/swift/pull/17668)
* Bugs: [SR-6362](https://bugs.swift.org/browse/SR-6362)
* Review: [Discussion thread](https://forums.swift.org/t/se-0200-enhancing-string-literals-delimiters-to-support-raw-text/15420), [Announcement thread](https://forums.swift.org/t/accepted-se-0200-enhancing-string-literals-delimiters-to-support-raw-text/15822/2)
@@ -150,9 +150,9 @@ Removing escaped snippets to external files makes code review harder. Escaping (
## Initial Proposal
-"Raw-mode" strings were first discussed during the [SE-0168 Multi-Line String literals](https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md) review and postponed for later consideration. This proposal focuses on raw strings to allow the entry of single and multi-line string literals.
+"Raw-mode" strings were first discussed during the [SE-0168 Multi-Line String literals](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md) review and postponed for later consideration. This proposal focuses on raw strings to allow the entry of single and multi-line string literals.
-The first iteration of [SE-0200](https://github.com/apple/swift-evolution/blob/102b2f2770f0dab29f254a254063847388647a4a/proposals/0200-raw-string-escaping.md) proposed adopting Python's model, using `r"...raw string..."`. The proposal was returned for revision with the [following feedback](https://forums.swift.org/t/returned-for-revision-se-0200-raw-mode-string-literals/11630):
+The first iteration of [SE-0200](https://github.com/swiftlang/swift-evolution/blob/102b2f2770f0dab29f254a254063847388647a4a/proposals/0200-raw-string-escaping.md) proposed adopting Python's model, using `r"...raw string..."`. The proposal was returned for revision with the [following feedback](https://forums.swift.org/t/returned-for-revision-se-0200-raw-mode-string-literals/11630):
> During the review discussion, a few issues surfaced with the proposal, including:
>
@@ -361,7 +361,7 @@ The same behavior is extended to multi-line strings:
"""#
```
-New line escaping works as per [SE-182](https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md):
+New line escaping works as per [SE-182](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md):
```
#"""
diff --git a/proposals/0202-random-unification.md b/proposals/0202-random-unification.md
index 81744c6ea4..48eeb31a90 100644
--- a/proposals/0202-random-unification.md
+++ b/proposals/0202-random-unification.md
@@ -2,7 +2,7 @@
* Proposal: [SE-0202](0202-random-unification.md)
* Author: [Alejandro Alonso](https://github.com/Azoy)
-* Review Manager: [Ben Cohen](http://github.com/AirspeedSwift/)
+* Review Manager: [Ben Cohen](https://github.com/AirspeedSwift/)
* Status: **Implemented (Swift 4.2)**
* Implementation: [apple/swift#12772](https://github.com/apple/swift/pull/12772)
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-020-random-unification/12040)
diff --git a/proposals/0203-rename-sequence-elements-equal.md b/proposals/0203-rename-sequence-elements-equal.md
index b9df559ec9..4d5391bee1 100644
--- a/proposals/0203-rename-sequence-elements-equal.md
+++ b/proposals/0203-rename-sequence-elements-equal.md
@@ -12,7 +12,7 @@
The behavior of `Sequence.elementsEqual` is confusing to users given its name. Having surveyed alternative solutions to this problem, it is proposed that the method be renamed to `Sequence.elementsEqualInIterationOrder`.
-Swift-evolution thread: [Rename Sequence.elementsEqual](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171009/040362.html)
+Swift-evolution thread: [Rename Sequence.elementsEqual](https://forums.swift.org/t/draft-rename-sequence-elementsequal/6821)
## Motivation
@@ -28,7 +28,7 @@ set1.elementsEqual(set2) // false
In almost all circumstances where a set is compared to another set or a dictionary is compared to another dictionary, users should use `==`, which is order-insensitive, instead of `elementsEqual(_:)`, which is order-sensitive.
-[As Michael Ilseman explains](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171016/040544.html):
+[As Michael Ilseman explains](https://forums.swift.org/t/draft-rename-sequence-elementsequal/6821/152):
> We have two forms of equality we're talking about: equality of Sequence and equality of the elements of Sequences in their respective ordering. `==` covers the former, and I'll use the existing (harmful) name of `elementsEqual` for the latter.
>
diff --git a/proposals/0204-add-last-methods.md b/proposals/0204-add-last-methods.md
index 559e60c55a..8726f9cadb 100644
--- a/proposals/0204-add-last-methods.md
+++ b/proposals/0204-add-last-methods.md
@@ -118,7 +118,7 @@ This change does not affect ABI stability or API resilience beyond the addition
- Another previous proposal included renaming `index(of:)` and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)`, respectively. A proposal after *that one* removed that source-breaking change. *This* version of the proposal adds the source-breaking change back in again.
-- An [alternative approach](https://github.com/apple/swift-evolution/pull/773#issuecomment-351148673) is to add a defaulted `options` parameter to the existing searching methods, like so:
+- An [alternative approach](https://github.com/swiftlang/swift-evolution/pull/773#issuecomment-351148673) is to add a defaulted `options` parameter to the existing searching methods, like so:
```swift
let a = [20, 30, 10, 40, 20, 30, 10, 40, 20]
diff --git a/proposals/0206-hashable-enhancements.md b/proposals/0206-hashable-enhancements.md
index 7e23b346b9..289cb6d985 100644
--- a/proposals/0206-hashable-enhancements.md
+++ b/proposals/0206-hashable-enhancements.md
@@ -9,7 +9,7 @@
[apple/swift#14913](https://github.com/apple/swift/pull/14913) (standard library, underscored),
[apple/swift#16009](https://github.com/apple/swift/pull/16009) (`Hasher` interface),
[apple/swift#16073](https://github.com/apple/swift/pull/16073) (automatic synthesis, de-underscoring)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/f5a020ec79cdb64fc8700af91b1a1ece2d2fb141/proposals/0206-hashable-enhancements.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/f5a020ec79cdb64fc8700af91b1a1ece2d2fb141/proposals/0206-hashable-enhancements.md)
Value`) and `init()`. To cover all of these cases, we would need a
+-> Value`) and `init()`. To cover all of these cases, we would need
several related-but-subtly-different protocols.
-The second issue that, even if there were a single `PropertyWrapper`
+The second issue is that, even if there were a single `PropertyWrapper`
protocol, we don't know of any useful generic algorithms or data
structures that seem to be implemented in terms of only
`PropertyWrapper`.
@@ -1339,7 +1282,7 @@ much debate. A number of alternatives have been proposed, including longer `#`-b
### The 2015-2016 property behaviors design
Property wrappers address a similar set of use cases to *property behaviors*, which were [proposed and
-reviewed](https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md)
+reviewed](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md)
in late 2015/early 2016. The design did not converge, and the proposal
was deferred. This proposal picks up the thread, using much of the
same motivation and some design ideas, but attempting to simplify the
@@ -1527,7 +1470,7 @@ var wrappedValue: Value {
}
```
-The same model could be extended to static properties of types (passing the metatype instance for the enclosing `self`) as well as global and local properties (no enclsoing `self`), although we would also need to extend key path support to static, global, and local properties to do so.
+The same model could be extended to static properties of types (passing the metatype instance for the enclosing `self`) as well as global and local properties (no enclosing `self`), although we would also need to extend key path support to static, global, and local properties to do so.
### Delegating to an existing property
@@ -1542,6 +1485,39 @@ One could express this either by naming the property directly (as above) or, for
## Revisions
+### Changes from the accepted proposal
+
+This proposal originally presented an example of implementing atomic operations using a property wrapper interface. This example was misleading because it would require additional compiler and library features to work correctly.
+
+Programmers looking for atomic operations can use the [Swift Atomics](https://github.com/apple/swift-atomics) package.
+
+For those who have already attempted to implement something similar, here is the original example, and why it is incorrect:
+
+```swift
+@propertyWrapper
+class Atomic {
+ private var _value: Value
+
+ init(wrappedValue: Value) {
+ self._value = wrappedValue
+ }
+
+ var wrappedValue: Value {
+ get { return load() }
+ set { store(newValue: newValue) }
+ }
+
+ func load(order: MemoryOrder = .relaxed) { ... }
+ func store(newValue: Value, order: MemoryOrder = .relaxed) { ... }
+ func increment() { ... }
+ func decrement() { ... }
+}
+```
+
+As written, this property wrapper does not access its wrapped value atomically. `wrappedValue.getter` reads the entire `_value` property nonatomically, *before* calling the atomic `load` operation on the copied value. Similarly, `wrappedValue.setter` writes the entire `_value` property nonatomically *after* calling the atomic `store` operation. So, in fact, there is no atomic access to the shared class property, `_value`.
+
+Even if the getter and setter could be made atomic, useful atomic operations, like increment, cannot be built from atomic load and store primitives. The property wrapper in fact encourages race conditions by allowing mutating methods, such as `atomicInt += 1`, to be directly invoked on the nonatomic copy of the wrapped value.
+
### Changes from the third reviewed version
* `init(initialValue:)` has been renamed to `init(wrappedValue:)` to match the name of the property.
@@ -1569,4 +1545,4 @@ One could express this either by naming the property directly (as above) or, for
## Acknowledgments
-This proposal was greatly improved throughout its [first pitch](https://forums.swift.org/t/pitch-property-delegates/21895) by many people. Harlan Haskins, Brent Royal-Gordon, Adrian Zubarev, Jordan Rose and others provided great examples of uses of property wrappers (several of which are in this proposal). Adrian Zubarev and Kenny Leung helped push on some of the core assumptions and restrictions of the original proposal, helping to make it more general. Vini Vendramini and David Hart helped tie this proposal together with custom attributes, which drastically reduced the syntactic surface area of this proposal.
+This proposal was greatly improved throughout its [first pitch](https://forums.swift.org/t/pitch-property-delegates/21895) by many people. Harlan Haskins, Becca Royal-Gordon, Adrian Zubarev, Jordan Rose and others provided great examples of uses of property wrappers (several of which are in this proposal). Adrian Zubarev and Kenny Leung helped push on some of the core assumptions and restrictions of the original proposal, helping to make it more general. Vini Vendramini and David Hart helped tie this proposal together with custom attributes, which drastically reduced the syntactic surface area of this proposal.
diff --git a/proposals/0259-approximately-equal.md b/proposals/0259-approximately-equal.md
index ff167fbb1b..c8a1249e4f 100644
--- a/proposals/0259-approximately-equal.md
+++ b/proposals/0259-approximately-equal.md
@@ -133,7 +133,7 @@ extension FloatingPoint {
tolerance: Self = Self.ulpOfOne.squareRoot()
) -> Bool {
// tolerances outside of [.ulpOfOne,1) yield well-defined but useless results,
- // so this is enforced by an assert rathern than a precondition.
+ // so this is enforced by an assert rather than a precondition.
assert(tolerance >= .ulpOfOne && tolerance < 1, "tolerance should be in [.ulpOfOne, 1).")
// The simple computation below does not necessarily give sensible
// results if one of self or other is infinite; we need to rescale
diff --git a/proposals/0260-library-evolution.md b/proposals/0260-library-evolution.md
index fbd6bc4724..e14420908c 100644
--- a/proposals/0260-library-evolution.md
+++ b/proposals/0260-library-evolution.md
@@ -27,7 +27,7 @@ _Note: this proposal will use the word "field" to mean "stored instance property
As of Swift 5, libraries are able to declare a stable ABI, allowing a library binary to be replaced with a newer version without requiring client programs to be recompiled.
-What consitutes the ABI of a library differs from language to language. In C and C++, the public ABI for a library includes information that ideally would be kept purely as an implementation detail. For example, the _size_ of a struct is fixed as part of the ABI, and is known to the library user at compile time. This prevents adding new fields to that type in later releases once the ABI is declared stable. If direct access to fields is allowed, the _layout_ of the struct can also become part of the ABI, so fields cannot then be reordered.
+What constitutes the ABI of a library differs from language to language. In C and C++, the public ABI for a library includes information that ideally would be kept purely as an implementation detail. For example, the _size_ of a struct is fixed as part of the ABI, and is known to the library user at compile time. This prevents adding new fields to that type in later releases once the ABI is declared stable. If direct access to fields is allowed, the _layout_ of the struct can also become part of the ABI, so fields cannot then be reordered.
This often leads to manual workarounds. A common technique is to have the struct hold only a pointer to an "impl" type, which holds the actual stored properties. All access to these properties is made via function calls, which can be updated to handle changes to the layout of the "impl" type. This has some obvious downsides:
@@ -40,7 +40,7 @@ A similar challenge occurs with Swift enums. As discussed in [SE-0192][], introd
The goal of this proposal is to reduce the burden on library developers by building into the compiler an automatic mechanism to reserve the flexibility to alter the internal representation of structs and enums, without manual workarounds. This mechanism can be implemented in such a way that optimizations such as stack allocation or contiguous inline storage of structs can still happen, while leaving the size of the type to be determined at runtime.
- [SE-0192]: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
+ [SE-0192]: https://github.com/swiftlang/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
## Proposed solution
@@ -109,7 +109,7 @@ This affects what changes to the struct's fields affect the ABI of the containin
> Note: This proposal is implemented already and in use by the standard library, albeit under different names. The command-line flag is `-enable-library-evolution`; the attribute is `@_fixed_layout` for structs, and `@_frozen` for enums.
- [SE-0193]: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
+ [SE-0193]: https://github.com/swiftlang/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
#### Guarantees
@@ -134,7 +134,7 @@ That said, the compiler is allowed to use its knowledge of the struct's contents
This proposal does not change either of these guarantees.
[trivial]: https://docs.microsoft.com/en-us/cpp/cpp/trivial-standard-layout-and-pod-types
- [SE-0055]: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
+ [SE-0055]: https://github.com/swiftlang/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
### `@frozen` on `enum` types
diff --git a/proposals/0261-identifiable.md b/proposals/0261-identifiable.md
index 48fcc60f47..c19eda84de 100644
--- a/proposals/0261-identifiable.md
+++ b/proposals/0261-identifiable.md
@@ -101,7 +101,7 @@ doesn't move to the standard library Swift programmers
will need to continue using their own variation of this protocol and will need
to ensure it is able co-exist with other similar definitions found in other frameworks higher
up the dependency stack. Unfortunately none these variations
-are likey to be compatible with one another.
+are likely to be compatible with one another.
## Proposed solution
diff --git a/proposals/0262-demangle.md b/proposals/0262-demangle.md
index 7113692afe..447a02c7f9 100644
--- a/proposals/0262-demangle.md
+++ b/proposals/0262-demangle.md
@@ -92,7 +92,7 @@ This proposal includes a trivial `(String) -> String?` version of the function,
```swift
// Swift.Int requires 10 bytes = 9 characters + 1 null terminator
-// Give this 9 to excercise truncation
+// Give this 9 to exercise truncation
let buffer = UnsafeMutableBufferPointer.allocate(capacity: 9)
defer { buffer.deallocate() }
diff --git a/proposals/0263-string-uninitialized-initializer.md b/proposals/0263-string-uninitialized-initializer.md
index e0f7bed605..826f27abe9 100644
--- a/proposals/0263-string-uninitialized-initializer.md
+++ b/proposals/0263-string-uninitialized-initializer.md
@@ -3,8 +3,9 @@
* Proposal: [SE-0263](0263-string-uninitialized-initializer.md)
* Author: [David Smith](https://github.com/Catfish-Man)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Accepted**
-* Implementation: [apple/swift#23409](https://github.com/apple/swift/pull/23409)
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift#26007](https://github.com/apple/swift/pull/26007),
+ [apple/swift#30106](https://github.com/apple/swift/pull/30106)
* Bug: [SR-10288](https://bugs.swift.org/browse/SR-10288)
## Introduction
diff --git a/proposals/0264-stdlib-preview-package.md b/proposals/0264-stdlib-preview-package.md
index 7c09bae19b..bb37b2d3d6 100644
--- a/proposals/0264-stdlib-preview-package.md
+++ b/proposals/0264-stdlib-preview-package.md
@@ -3,13 +3,14 @@
* Proposal: [SE-0264](0264-stdlib-preview-package.md)
* Authors: [Ben Cohen](https://github.com/airspeedswift), [Max Moiseev](https://github.com/moiseev), [Nate Cook](https://github.com/natecook1000)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Active review (December 2...December 10)**
+* Status: **Implemented**
+* Decision Notes: [Rationale](https://forums.swift.org/t/se-0264-review-2-standard-library-preview-package/31288/16)
* Implementation:
- 1. [apple/swift-evolution#1089](https://github.com/apple/swift-evolution/pull/1089)
- 2. [apple/swift-evolution#1090](https://github.com/apple/swift-evolution/pull/1090)
- 3. [apple/swift-evolution#1091](https://github.com/apple/swift-evolution/pull/1091)
+ 1. [swiftlang/swift-evolution#1089](https://github.com/swiftlang/swift-evolution/pull/1089)
+ 2. [swiftlang/swift-evolution#1090](https://github.com/swiftlang/swift-evolution/pull/1090)
+ 3. [swiftlang/swift-evolution#1091](https://github.com/swiftlang/swift-evolution/pull/1091)
* Pitch Discussion: [Pitch: Standard Library Preview Package](https://forums.swift.org/t/pitch-standard-library-preview-package/27202)
-* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/1547e503376bca2c64c57c96b1f87d5e01a094c3/proposals/0264-stdlib-preview-package.md)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/1547e503376bca2c64c57c96b1f87d5e01a094c3/proposals/0264-stdlib-preview-package.md)
* Previous Review: [SE-0264 — Standard Library Preview Package](https://forums.swift.org/t/se-0264-standard-library-preview-package/29068)
* Previous Decision: [Returned for Revision](https://forums.swift.org/t/returned-for-revision-se-0264-standard-library-preview-package/29865)
@@ -35,7 +36,7 @@ For the purposes of this document, we will refer to the individual packages and
### Facilitating Rapid Adoption and Feedback
-It is common for a feature proposed and accepted through Swift Evolution and added to the standard library to wait for months before it gets any real life usage. Take [SE-0199](https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md) (the introduction of `toggle`) for example. It was [accepted](https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681) almost 6 months before Swift 4.2 was released.
+It is common for a feature proposed and accepted through Swift Evolution and added to the standard library to wait for months before it gets any real life usage. Take [SE-0199](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0199-bool-toggle.md) (the introduction of `toggle`) for example. It was [accepted](https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681) almost 6 months before Swift 4.2 was released.
Even though all additions go through a thorough review, there is no substitute for feedback from real-world usage in production. Sometimes we discover that the API is not quite as good as it might have been.
diff --git a/proposals/0266-synthesized-comparable-for-enumerations.md b/proposals/0266-synthesized-comparable-for-enumerations.md
index 5ee3b775a9..1c43e83890 100644
--- a/proposals/0266-synthesized-comparable-for-enumerations.md
+++ b/proposals/0266-synthesized-comparable-for-enumerations.md
@@ -1,14 +1,15 @@
# Synthesized `Comparable` conformance for `enum` types
* Proposal: [SE-0266](0266-synthesized-comparable-for-enumerations.md)
-* Author: [Kelvin Ma (taylorswift)](https://forums.swift.org/u/taylorswift)
+* Author: [Diana Ma (taylorswift)](https://github.com/tayloraswift)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Accepted**
+* Status: **Implemented (Swift 5.3)**
* Implementation: [apple/swift#25696](https://github.com/apple/swift/pull/25696)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0266-synthesized-comparable-conformance-for-enum-types/29854)
## Introduction
-[SE-185](https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md) 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.
+[SE-185](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md) 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.
## Motivation
diff --git a/proposals/0267-where-on-contextually-generic.md b/proposals/0267-where-on-contextually-generic.md
index af35452c5f..812fb39da5 100644
--- a/proposals/0267-where-on-contextually-generic.md
+++ b/proposals/0267-where-on-contextually-generic.md
@@ -3,23 +3,23 @@
* Proposal: [SE-0267](0267-where-on-contextually-generic.md)
* Author: [Anthony Latsis](https://github.com/AnthonyLatsis)
* Review Manager: [Joe Groff](https://github.com/jckarter)
-* Status: **Accepted**
+* Status: **Implemented (Swift 5.3)**
* Implementation: [apple/swift#23489](https://github.com/apple/swift/pull/23489)
+* Decision Notes: [Review](https://forums.swift.org/t/se-0267-where-clauses-on-contextually-generic-declarations/30051/49), [Announcement](https://forums.swift.org/t/accepted-se-0267-where-clauses-on-contextually-generic-declarations/30474)
## Introduction
-This proposal aims to lift the mostly artificial restriction on attaching `where` clauses to declarations that reference only outer generic parameters. Simply put, this means you no longer have to worry about the `'where' clause cannot be attached` error inside most generic contexts.
+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:
```swift
struct Box {
- func sequence() -> [Box] where Wrapped: Sequence { ... }
+ func boxes() -> [Box] where Wrapped: Sequence { ... }
}
```
-> Only declarations that already support a generic parameter list will be allowed to carry a `where` clause inside a generic
-> context. Generic properties, conditional protocol requirements and `Self` constraints on class methods are out of scope for the current proposal.
-> For instance, the following remains an error:
+> The current proposal only covers member declarations that already support a generic parameter list, that is, properties and unsupported constraints on protocol requirements are out of scope.
+> To illustrate, the following remains invalid:
> ```swift
> protocol P {
> // error: Instance method requirement 'foo(arg:)' cannot add constraint 'Self: Equatable' on 'Self'
@@ -31,10 +31,10 @@ struct Box {
> func foo() where Self: Equatable
> }
> ```
-> Whereas placing a constraint on an extension member rather than the extension itself becomes possible:
+> Whereas placing constraints on an extension member rather than the extension itself becomes possible:
> ```swift
> extension P {
-> func bar() where Self: Equatable { }
+> func bar() where Self: Equatable { ... }
> }
> ```
@@ -42,10 +42,10 @@ struct Box {
## Motivation
-Today, `where` clauses on contextually generic declarations, including protocol extension members, are expressed indirectly by placing them inside conditional extensions. Unless constraints are identical, every such declaration requires a separate extension.
-This dependence on extensions can be an obstacle to grouping semantically related APIs, stacking up constraints, and sometimes the legibility of heavily generic interfaces.
+Today, a contextual where clause on a member declaration can only be expressed indirectly by placing the member inside a dedicated constrained extension. Unless constraints are identical, every such member requires a separate extension.
+This lack of flexibility is a potential obstacle to grouping semantically related APIs, stacking up constraints, and the legibility of heavily generic interfaces.
-It is reasonable to expect a `where` clause to work anywhere a constraint can be meaningfully imposed, that is, both of these structuring styles should be available to the user:
+It is reasonable to expect a `where` clause to "work" anywhere a constraint is meaningful, which is to say both of these structuring styles should be available to the user:
```swift
// 'Foo' can be any kind of nominal type declaration.
@@ -70,22 +70,22 @@ extension Foo where T: Sequence, T.Element: Equatable {
func specialCaseFoo() where T.Element == Character { ... }
}
```
-A step towards generalizing `where` clause usage is an obvious and farsighted improvement to the generics
-system with numerous future applications, including generic properties, [opaque types](https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md), [generalized
+A step towards generalizing `where` clause use is an obvious and farsighted improvement to the generics
+system with numerous future applications, including generic properties, [opaque types](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0244-opaque-result-types.md), [generalized
existentials](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials) and constrained protocol requirements.
## Detailed design
### Overrides
-Like their generic analogues, contextually generic methods can be overriden as long as Liskov substitutability is respected, which is to say the generic signature of the override must be *at least* as general as that of the overriden method.
+Because contextual `where` clauses are effectively visibility constraints, overrides adopting this feature must be at least as visible as the overridden method:
```swift
class Base {
- func foo() where T: Comparable { ... }
+ func foo() where T == Int { ... }
}
class Derived: Base {
- // OK, the possible substitutions for are a superset of those for
+ // OK, the substitutions for are a superset of those for
override func foo() where T: Equatable { ... }
}
```
diff --git a/proposals/0268-didset-semantics.md b/proposals/0268-didset-semantics.md
index 6d99bea812..782c01c1d9 100644
--- a/proposals/0268-didset-semantics.md
+++ b/proposals/0268-didset-semantics.md
@@ -3,7 +3,7 @@
* Proposal: [SE-0268](0268-didset-semantics.md)
* Author: [Suyash Srijan](https://github.com/theblixguy)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
-* Status: **Accepted**
+* Status: **Implemented (Swift 5.3)**
* Implementation: [apple/swift#26632](https://github.com/apple/swift/pull/26632)
* Bug: [SR-5982](https://bugs.swift.org/browse/SR-5982)
diff --git a/proposals/0269-implicit-self-explicit-capture.md b/proposals/0269-implicit-self-explicit-capture.md
index 93d5703fe2..272a4386ab 100644
--- a/proposals/0269-implicit-self-explicit-capture.md
+++ b/proposals/0269-implicit-self-explicit-capture.md
@@ -3,7 +3,7 @@
* Proposal: [SE-0269](0269-implicit-self-explicit-capture.md)
* Author: [Frederick Kellison-Linn](https://github.com/jumhyn)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
-* Status: **Accepted**
+* Status: **Implemented (Swift 5.3)**
* Implementation: [apple/swift#23934](https://github.com/apple/swift/pull/23934)
* Bug: [SR-10218](https://bugs.swift.org/browse/SR-10218)
* Forum threads: [Discussion](https://forums.swift.org/t/review-capture-semantics-of-self/22017), [Pitch](https://forums.swift.org/t/allow-implicit-self-in-escaping-closures-when-self-is-explicitly-captured/22590), [Review thread](https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376)
@@ -35,8 +35,8 @@ struct Test {
work()
}
func method() {
- execute {
- x += 1
+ execute {
+ print(x)
}
}
}
@@ -65,7 +65,7 @@ It also results in a lot of unnecessary repetition. The motivation for requiring
In codebases that make heavy use of asynchronous code, such as clients of [PromiseKit](https://github.com/mxcl/PromiseKit), or even Apple's new [Combine](https://developer.apple.com/documentation/combine) and [SwiftUI](https://developer.apple.com/documentation/swiftui) libraries, maintainers must either choose to adopt style guides which require the use of explicit `self` in all cases, or else resign to the reality that explicit usage of `self` will appear inconsistently throughout the code. Given that Apple's preferred/recommended style is to omit `self` where possible (as evidenced by examples throughout [The Swift Programming Language](https://docs.swift.org/swift-book/) and the [SwiftUI Tutorials](https://developer.apple.com/tutorials/swiftui)), having any asynchronous code littered with `self.` is a suboptimal state of affairs.
-The error is also overly conservative—it will prevent the usage of implicit `self` even when it is very unlikely that the capture of `self` will somehow cause a reference cycle. With function builders in SwiftUI, the automatic resolution to the "make capture semantics explicit" error (and indeed, the fix-it that is currently supplied to the programmer) is just to slap a `self.` on wherever the compiler tells you to. While this likely fine when `self` is a value type, building this habit could cause users to ignore the error and apply the fix-it in cases where it is not in fact appropriate.
+The error is also overly conservative—it will prevent the usage of implicit `self` even when it is very unlikely that the capture of `self` will somehow cause a reference cycle. With function builders in SwiftUI, the automatic resolution to the "make capture semantics explicit" error (and indeed, the fix-it that is currently supplied to the programmer) is just to slap a `self.` on wherever the compiler tells you to. While this is likely fine when `self` is a value type, building this habit could cause users to ignore the error and apply the fix-it in cases where it is not in fact appropriate.
There are also cases that are just as (if not more) likely to cause reference cycles that the tool currently misses. Once such instance is discussed in **Future Directions** below. These false negatives are not addressed in this proposal, but improving the precision of this diagnostic will make the tool more powerful and less likely to be dismissed if (or when) new diagnostic cases are introduced.
@@ -126,7 +126,7 @@ The existing errors and fix-its have their language updated accordingly to indic
Error: call to method in closure requires explicit use of 'self' to make capture semantics explicit.
```
-The new fix-it for explicitly capturing `self` will take slightly different forms depending on whether there is a capture list already present ("insert '`self, `'"), whether there are explicit parameters ("insert '`[self]`'"), and whether the user the user has already captured a variable with the name `self` (in which case the fix-it would not be offered). Since empty capture lists are allowed (`{ [] in ... }`), the fix-it will cover this case too.
+The new fix-it for explicitly capturing `self` will take slightly different forms depending on whether there is a capture list already present ("insert '`self, `'"), whether there are explicit parameters ("insert '`[self]`'"), and whether the user has already captured a variable with the name `self` (in which case the fix-it would not be offered). Since empty capture lists are allowed (`{ [] in ... }`), the fix-it will cover this case too.
This new rule would only apply when `self` is captured directly, and with the name `self`. This includes captures of the form `[self = self]` but would still not permit implicit `self` if the capture were `[y = self]`. In the unusual event that the user has captured another variable with the name `self` (e.g. `[self = "hello"]`), we will offer a note that this does not enable use of implicit `self` (in addition to the existing error attached to the attempted use of implicit `self`):
@@ -140,7 +140,7 @@ If the user has a capture of `weak self` already, we offer a special diagnostic
Note: weak capture of 'self' here does not enable implicit 'self'.
```
-If either of the two above notes are present, we will not offer the usual fix-its for resolving this error, since the code inserted would be erroneous.
+If either of the two above notes is present, we will not offer the usual fix-its for resolving this error, since the code inserted would be erroneous.
## Source compatibility
diff --git a/proposals/0270-rangeset-and-collection-operations.md b/proposals/0270-rangeset-and-collection-operations.md
index 1be2c837db..f9c3e224f7 100644
--- a/proposals/0270-rangeset-and-collection-operations.md
+++ b/proposals/0270-rangeset-and-collection-operations.md
@@ -1,13 +1,12 @@
# Add Collection Operations on Noncontiguous Elements
* Proposal: [SE-0270](0270-rangeset-and-collection-operations.md)
-* Author: [Nate Cook](https://github.com/natecook1000)
+* Authors: [Nate Cook](https://github.com/natecook1000), [Jeremy Schonfeld](https://github.com/jmschonfeld)
* Review Manager: [John McCall](https://github.com/rjmccall)
-* Status: **Accepted**
-* Implementation: [apple/swift#28161](https://github.com/apple/swift/pull/28161)
-* Previous Revisions: [1](https://github.com/apple/swift-evolution/blob/9b5957c00e7483ab8664afe921f989ed1394a666/proposals/0270-rangeset-and-collection-operations.md), [2](https://github.com/apple/swift-evolution/blob/b17d85fcaf38598fd2ea19641d0e9c26c96747ec/proposals/0270-rangeset-and-collection-operations.md)
-* Reviews: [1](https://forums.swift.org/t/se-0270-add-collection-operations-on-noncontiguous-elements/30691), [2](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653), [3](https://forums.swift.org/t/se-0270-review-3-add-collection-operations-on-noncontiguous-elements/32839)
-* Decision Notes: [1](https://forums.swift.org/t/returned-for-revision-se-0270-add-collection-operations-on-noncontiguous-elements/31484), [2](https://forums.swift.org/t/revised-se-0270-add-collection-operations-on-noncontiguous-elements/32840), [3](https://forums.swift.org/t/accepted-se-0270-add-collection-operations-on-noncontiguous-elements/33270)
+* Status: **Implemented (Swift 6.0)**
+* Implementation: [apple/swift#69766](https://github.com/apple/swift/pull/69766)
+* Previous Revisions: [1](https://github.com/swiftlang/swift-evolution/blob/9b5957c00e7483ab8664afe921f989ed1394a666/proposals/0270-rangeset-and-collection-operations.md), [2](https://github.com/swiftlang/swift-evolution/blob/b17d85fcaf38598fd2ea19641d0e9c26c96747ec/proposals/0270-rangeset-and-collection-operations.md), [3](https://github.com/swiftlang/swift-evolution/blob/54d85f65fefce924eb4d5bf10dd633e81f063d11/proposals/0270-rangeset-and-collection-operations.md)
+* Review: ([pitch](https://forums.swift.org/t/pitch-add-rangeset-and-related-collection-operations/29961)) ([first review](https://forums.swift.org/t/se-0270-add-collection-operations-on-noncontiguous-elements/30691)) ([first revision](https://forums.swift.org/t/returned-for-revision-se-0270-add-collection-operations-on-noncontiguous-elements/31484)) ([second review](https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653)) ([second revision](https://forums.swift.org/t/revised-se-0270-add-collection-operations-on-noncontiguous-elements/32840)) ([third review](https://forums.swift.org/t/se-0270-review-3-add-collection-operations-on-noncontiguous-elements/32839)) ([acceptance into preview package](https://forums.swift.org/t/accepted-se-0270-add-collection-operations-on-noncontiguous-elements/33270)) ([fourth pitch](https://forums.swift.org/t/pitch-revision-4-add-collection-operations-on-noncontiguous-elements/68345)) ([fourth review](https://forums.swift.org/t/se-0270-fourth-review-add-collection-operations-on-noncontiguous-elements/68855)) ([acceptance](https://forums.swift.org/t/accepted-se-0270-add-collection-operations-on-noncontiguous-elements/69080))
## Introduction
@@ -17,7 +16,7 @@ We can use a `Range` to refer to a group of consecutive positions in a co
There are varied uses for tracking multiple elements in a collection, such as maintaining the selection in a list of items, or refining a filter or search result set after getting more input from a user.
-The Foundation data type most suited for this purpose, `IndexSet`, uses integers only, which limits its usefulness to arrays and other random-access collection types. The standard library is missing a collection that can efficiently store ranges of indices, and is missing the operations that you might want to perform with such a collection. These operations themselves can be challenging to implement correctly, and have performance traps as well — see last year's [Embracing Algorithms](https://developer.apple.com/videos/wwdc/2018/?id=223) WWDC talk for a demonstration.
+The Foundation data type most suited for this purpose, `IndexSet`, uses integers only, which limits its usefulness to arrays and other random-access collection types. The standard library is missing a collection that can efficiently store ranges of indices, and is missing the operations that you might want to perform with such a collection. These operations themselves can be challenging to implement correctly, and have performance traps as well — see WWDC 2018's [Embracing Algorithms](https://developer.apple.com/videos/wwdc/2018/?id=223) talk for a demonstration.
## Proposed solution
@@ -27,7 +26,7 @@ This proposal adds a `RangeSet` type for representing multiple, noncontiguous ra
var numbers = Array(1...15)
// Find the indices of all the even numbers
-let indicesOfEvens = numbers.subranges(where: { $0.isMultiple(of: 2) })
+let indicesOfEvens = numbers.indices(where: { $0.isMultiple(of: 2) })
// Perform an operation with just the even numbers
let sumOfEvens = numbers[indicesOfEvens].reduce(0, +)
@@ -46,7 +45,7 @@ let rangeOfEvens = numbers.moveSubranges(indicesOfEvens, to: numbers.startIndex)
```swift
/// A set of values of any comparable value, represented by ranges.
-public struct RangeSet {
+public struct RangeSet: Equatable, CustomStringConvertible {
/// Creates an empty range set.
public init() {}
@@ -79,9 +78,10 @@ public struct RangeSet {
/// the overlap between `range` and the set's existing ranges.
public mutating func remove(contentsOf range: Range)
}
-```
-`RangeSet` conforms to `Equatable`, to `CustomStringConvertible`, and, when its `Bound` type conforms to `Hashable`, to `Hashable`.
+extension RangeSet: Sendable where Bound: Sendable {}
+extension RangeSet: Hashable where Bound: Hashable {}
+```
#### Conveniences for working with collection indices
@@ -107,9 +107,13 @@ extension RangeSet {
/// valid index of `collection` that isn't the collection's `endIndex`.
/// - collection: The collection that contains `index`.
///
+ /// - Returns: `true` if the range set was modified, or `false` if
+ /// the given `index` was already in the range set.
+ ///
/// - Complexity: O(*n*), where *n* is the number of ranges in the range
/// set.
- public mutating func insert(_ index: Bound, within collection: C)
+ @discardableResult
+ public mutating func insert(_ index: Bound, within collection: C) -> Bool
where C: Collection, C.Index == Bound
/// Removes the range that contains only the specified index from the range
@@ -135,7 +139,7 @@ You can access the individual indices represented by the range set by using it a
```swift
extension RangeSet {
- public struct Ranges: RandomAccessCollection {
+ public struct Ranges: RandomAccessCollection, Equatable, CustomStringConvertible {
public var startIndex: Int { get }
public var endIndex: Int { get }
public subscript(i: Int) -> Range
@@ -144,6 +148,9 @@ extension RangeSet {
/// A collection of the ranges that make up the range set.
public var ranges: Ranges { get }
}
+
+extension RangeSet.Ranges: Sendable where Bound: Sendable {}
+extension RangeSet.Ranges: Hashable where Bound: Hashable {}
```
The ranges that are exposed through this collection are always in ascending order, are never empty, and never overlap or adjoin. For this reason, inserting an empty range or a range that is subsumed by the ranges already in the set has no effect on the range set. Inserting a range that adjoins an existing range simply extends that range.
@@ -184,18 +191,15 @@ extension RangeSet {
public func isSuperset(of other: RangeSet) -> Bool
public func isStrictSubset(of other: RangeSet) -> Bool
public func isStrictSuperset(of other: RangeSet) -> Bool
+ public func isDisjoint(with other: RangeSet) -> Bool
}
```
-#### Storage
-
-`RangeSet` stores its ranges in a custom type that optimizes the storage for known, simple `Bound` types. This custom type will avoid allocating extra storage for the common cases of empty and single-range sets.
-
### New `Collection` APIs
#### Finding multiple elements
-Akin to the `firstIndex(...)` and `lastIndex(...)` methods, this proposal introduces `subranges(where:)` and `subranges(of:)` methods that return a range set with the indices of all matching elements in a collection.
+Akin to the `firstIndex(...)` and `lastIndex(...)` methods, this proposal introduces `indices(where:)` and `indices(of:)` methods that return a range set with the indices of all matching elements in a collection.
```swift
extension Collection {
@@ -206,11 +210,11 @@ extension Collection {
///
/// let str = "Fresh cheese in a breeze"
/// let vowels: Set = ["a", "e", "i", "o", "u"]
- /// let allTheVowels = str.subranges(where: { vowels.contains($0) })
+ /// let allTheVowels = str.indices(where: { vowels.contains($0) })
/// // str[allTheVowels].count == 9
///
/// - Complexity: O(*n*), where *n* is the length of the collection.
- public func subranges(where predicate: (Element) throws -> Bool) rethrows
+ public func indices(where predicate: (Element) throws -> Bool) rethrows
-> RangeSet
}
@@ -222,11 +226,11 @@ extension Collection where Element: Equatable {
/// particular letter occurs in a string.
///
/// let str = "Fresh cheese in a breeze"
- /// let allTheEs = str.subranges(of: "e")
+ /// let allTheEs = str.indices(of: "e")
/// // str[allTheEs].count == 7
///
/// - Complexity: O(*n*), where *n* is the length of the collection.
- public func subranges(of element: Element) -> RangeSet
+ public func indices(of element: Element) -> RangeSet
}
```
@@ -255,7 +259,7 @@ extension MutableCollection {
/// A collection wrapper that provides access to the elements of a collection,
/// indexed by a set of indices.
-public struct DiscontiguousSlice: Collection {
+public struct DiscontiguousSlice: Collection, CustomStringConvertible {
/// The collection that the indexed collection wraps.
public var base: Base { get set }
@@ -263,9 +267,11 @@ public struct DiscontiguousSlice: Collection {
/// collection.
public var subranges: RangeSet { get set }
+ public typealias SubSequence = Self
+
/// A position in an `DiscontiguousSlice`.
- struct Index: Comparable {
- // ...
+ public struct Index: Comparable {
+ public let base: Base.Index
}
public var startIndex: Index { get }
@@ -273,13 +279,19 @@ public struct DiscontiguousSlice: Collection {
public subscript(i: Index) -> Base.Element { get }
public subscript(bounds: Range) -> Self { get }
}
-```
-`DiscontiguousSlice` conforms to `Collection`, and conditionally conforms to `BidirectionalCollection` and `MutableCollection` if its base collection conforms.
+extension DiscontiguousSlice: BidirectionalCollection where Base: BidirectionalCollection {}
+extension DiscontiguousSlice: Sendable where Base: Sendable, Base.Index: Sendable {}
+extension DiscontiguousSlice: Equatable where Base.Element: Equatable {}
+extension DiscontiguousSlice: Hashable where Base.Element: Hashable {}
+
+extension DiscontiguousSlice.Index: Sendable where Base.Index: Sendable {}
+extension DiscontiguousSlice.Index: Hashable where Base.Index: Hashable {}
+```
#### Moving elements
-Within a mutable collection, you can move the elements represented by a range set to be in a contiguous range before the element at a specific index, while otherwise preserving element order. When moving elements, other elements slide over to fill gaps left by the elements that move. For that reason, this method returns the new range of the elements that are moved.
+Within a mutable collection, you can move the elements represented by a range set to be in a contiguous range before the element at a specific index, while otherwise preserving element order. When moving elements, other elements slide over to fill gaps left by the elements that move. For that reason, this method returns the new range of the elements that were previously located at the indices within the provided `RangeSet`.
```swift
extension MutableCollection {
@@ -290,7 +302,7 @@ extension MutableCollection {
/// them between `"i"` and `"j"`.
///
/// var letters = Array("ABCdeFGhijkLMNOp")
- /// let uppercaseRanges = letters.subranges(where: { $0.isUppercase })
+ /// let uppercaseRanges = letters.indices(where: { $0.isUppercase })
/// let rangeOfUppercase = letters.moveSubranges(uppercaseRanges, to: 10)
/// // String(letters) == "dehiABCFGLMNOjkp"
/// // rangeOfUppercase == 4..<13
@@ -298,7 +310,8 @@ extension MutableCollection {
/// - Parameters:
/// - subranges: The indices of the elements to move.
/// - insertionPoint: The index to use as the destination of the elements.
- /// - Returns: The new bounds of the moved elements.
+ /// - Returns: The new bounds of the moved elements that were previously located at
+ /// the indices provided by the RangeSet.
///
/// - Complexity: O(*n* log *n*) where *n* is the length of the collection.
@discardableResult
@@ -321,7 +334,7 @@ extension RangeReplaceableCollection {
///
/// var str = "The rain in Spain stays mainly in the plain."
/// let vowels: Set = ["a", "e", "i", "o", "u"]
- /// let vowelIndices = str.subranges(where: { vowels.contains($0) })
+ /// let vowelIndices = str.indices(where: { vowels.contains($0) })
///
/// str.removeSubranges(vowelIndices)
/// // str == "Th rn n Spn stys mnly n th pln."
@@ -342,7 +355,7 @@ extension Collection {
///
/// let str = "The rain in Spain stays mainly in the plain."
/// let vowels: Set = ["a", "e", "i", "o", "u"]
- /// let vowelIndices = str.subranges(where: { vowels.contains($0) })
+ /// let vowelIndices = str.indices(where: { vowels.contains($0) })
///
/// let disemvoweled = str.removingSubranges(vowelIndices)
/// print(String(disemvoweled))
@@ -425,6 +438,9 @@ In particular, the issue with this method stems from the fact that a collection
One potential solution is to offer an `(Index, Element) -> Bool` predicate for mutating methods instead of the currently standard `(Element) -> Bool` predicate. This kind of change should be considered for existing mutating methods, like `removeAll(where:)` and `partition(by:)`, as well as any future additions.
+### `DiscontiguousSlice` conformance to `MutableCollection`
+
+Previously, this proposal included a `MutableCollection` conformance for `DiscontiguousSlice` where the `Base` collection conformed to `MutableCollection`. However, after further consideration, this conformance was removed. The semantics of how this conformance should behave could be potentially unexpected and in addition to being slightly misleading the conformance would likely be hard to use in the first place. For these reasons, the conformance was removed.
### Other bikeshedding
@@ -434,3 +450,5 @@ There were also a suggestion that the methods for inserting and removing ranges
As a result of other feedback, some of the collection operations have been renamed. Instead of `removeAll(in:)` to match `removeAll(where:)`, removing the elements represented by a `RangeSet` is now `removeSubranges(_:)`, as a partner to `removeSubrange(_:)`. Similarly, the `gather(in:at:)` method has been renamed to `moveSubranges(_:to:)`. These names do better at continuing the naming scheme set up by `RangeReplaceableCollection`.
+Additionally, we have also chosen the names `indices(of:)` and `indices(where:)` as opposed to the previously suggested names of `ranges(of:)` and `ranges(where:)`. Since this proposal's last revision, `Collection` now has a `ranges(of:)` API that accepts a `RegexComponent` and returns a `[Range]`, so to avoid ambiguity we use the term "indices" here to provide a `RangeSet` value. The compiler does not find these functions ambiguous with the existing `indices` property on `Collection`.
+
diff --git a/proposals/0271-package-manager-resources.md b/proposals/0271-package-manager-resources.md
index 47e4aa1f81..f83bbad6ef 100644
--- a/proposals/0271-package-manager-resources.md
+++ b/proposals/0271-package-manager-resources.md
@@ -3,7 +3,11 @@
* Proposal: [SE-0271](0271-package-manager-resources.md)
* Authors: [Anders Bertelrud](https://github.com/abertelrud), [Ankit Aggarwal](https://github.com/aciidb0mb3r)
* Review Manager: [Boris Buegling](https://github.com/neonichu)
-* Status: **Accepted with revisions**
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift-package-manager#2381](https://github.com/apple/swift-package-manager/pull/2381),
+ [apple/swift-package-manager#2510](https://github.com/apple/swift-package-manager/pull/2510),
+ [apple/swift-package-manager#2520](https://github.com/apple/swift-package-manager/pull/2520),
+ [apple/swift-package-manager#2607](https://github.com/apple/swift-package-manager/pull/2607)
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0271-package-manager-resources/31021)
## Introduction
@@ -48,7 +52,7 @@ We propose the following to support resources in Swift packages:
- Add two new rules "copy" and "process" to existing list of rules. At this time, there will be no additional built-in file type that use these two new rules.
-- Vend an API in libSwiftPM to allow its clients to register additional file types supported by those clients. SwiftPM will automatially detect the matching files in a target and report them in the package model data structure. Similar to source files, package authors will not need to explicitly declare these files in the package manifest. This ability is useful for clients like Xcode to support platform-specific file types (such as `.metal`) without having to bake in a hardcoded list in SwiftPM’s codebase.
+- Vend an API in libSwiftPM to allow its clients to register additional file types supported by those clients. SwiftPM will automatically detect the matching files in a target and report them in the package model data structure. Similar to source files, package authors will not need to explicitly declare these files in the package manifest. This ability is useful for clients like Xcode to support platform-specific file types (such as `.metal`) without having to bake in a hardcoded list in SwiftPM’s codebase.
- Add a new `resources` parameter in `target` and `testTarget` APIs to allow declaring resource files explicitly.
diff --git a/proposals/0272-swiftpm-binary-dependencies.md b/proposals/0272-swiftpm-binary-dependencies.md
index 8ee1769062..993b70a5e6 100644
--- a/proposals/0272-swiftpm-binary-dependencies.md
+++ b/proposals/0272-swiftpm-binary-dependencies.md
@@ -3,7 +3,11 @@
* Proposal: [SE-0272](0272-swiftpm-binary-dependencies.md)
* Authors: [Braden Scothern](https://github.com/bscothern), [Daniel Dunbar](https://github.com/ddunbar), [Franz Busch](https://github.com/FranzBusch)
* Review Manager: [Boris Bügling](https://github.com/neonichu)
-* Status: **Accepted with revisions**
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift-package-manager#2509](https://github.com/apple/swift-package-manager/pull/2509),
+ [apple/swift-package-manager#2511](https://github.com/apple/swift-package-manager/pull/2511),
+ [apple/swift-package-manager#2514](https://github.com/apple/swift-package-manager/pull/2514),
+ [apple/swift-package-manager#2588](https://github.com/apple/swift-package-manager/pull/2588)
* Decision Notes: [First Review](https://forums.swift.org/t/returned-for-revision-se-0272-package-manager-binary-dependencies/30994), [Second Review](https://forums.swift.org/t/accepted-with-modifications-se-0272-package-manager-binary-dependencies/31926)
## Contents
diff --git a/proposals/0273-swiftpm-conditional-target-dependencies.md b/proposals/0273-swiftpm-conditional-target-dependencies.md
index a00bcabad1..720d6bc9f6 100644
--- a/proposals/0273-swiftpm-conditional-target-dependencies.md
+++ b/proposals/0273-swiftpm-conditional-target-dependencies.md
@@ -3,8 +3,9 @@
* Proposal: [SE-0273](0273-swiftpm-conditional-target-dependencies.md)
* Authors: [David Hart](https://github.com/hartbit)
* Review Manager: [Boris Buegling](https://github.com/neonichu)
-* Status: **Accepted**
-* Implementation: [apple/swift-package-manager#2428](https://github.com/apple/swift-package-manager/pull/2428)
+* Status: **Partially implemented (Swift 5.3 supports platform conditionals, but not configuration conditionals)**
+* Implementation: [apple/swift-package-manager#2428](https://github.com/apple/swift-package-manager/pull/2428),
+ [apple/swift-package-manager#2598](https://github.com/apple/swift-package-manager/pull/2598)
## Introduction
@@ -51,7 +52,7 @@ It is important to note that this proposal has no effect on dependency resolutio
### New `PackageDescription` API
-All the cases of the `Target.Dependency` enum will gain a new optional `BuildSettingCondition` argument. The current static factory functions for initializing those enums will be obsoleted in the version of the tools this proposal will appear in, and new functions will take their place, introducing a new optional argument:
+All the cases of the `Target.Dependency` enum will gain a new optional `TargetDependencyCondition` argument, a type with the same API as `BuildSettingCondition`. Creating a new type allows the APIs to evolve independently, if ever they have to, to support different condition types. The current static factory functions for initializing those enums will be obsoleted in the version of the tools this proposal will appear in, and new functions will take their place, introducing a new optional argument:
```swift
extension Target.Dependency {
@@ -63,7 +64,7 @@ extension Target.Dependency {
@available(_PackageDescription, introduced: 5.3)
public static func target(
name: String,
- condition: BuildSettingCondition? = nil
+ condition: TargetDependencyCondition? = nil
) -> Target.Dependency {
// ...
}
@@ -78,7 +79,7 @@ extension Target.Dependency {
public static func product(
name: String,
package: String? = nil,
- condition: BuildSettingCondition? = nil
+ condition: TargetDependencyCondition? = nil
) -> Target.Dependency {
// ...
}
@@ -92,7 +93,7 @@ extension Target.Dependency {
@available(_PackageDescription, introduced: 5.3)
public static func byName(
name: String,
- condition: BuildSettingCondition? = nil
+ condition: TargetDependencyCondition? = nil
) -> Target.Dependency {
// ...
}
diff --git a/proposals/0274-magic-file.md b/proposals/0274-magic-file.md
index a5ea1dcf8a..68a7016951 100644
--- a/proposals/0274-magic-file.md
+++ b/proposals/0274-magic-file.md
@@ -1,11 +1,12 @@
# Concise magic file names
* Proposal: [SE-0274](0274-magic-file.md)
-* Authors: [Brent Royal-Gordon](https://github.com/brentdax), [Dave DeLong](https://github.com/davedelong)
+* Authors: [Becca Royal-Gordon](https://github.com/beccadax), [Dave DeLong](https://github.com/davedelong)
* Review Manager: [Ben Cohen](https://github.com/airspeedswift/)
-* Original review: [Returned for revision](https://forums.swift.org/t/se-0274-concise-magic-file-names/32373/50)
-* Status: **Active Re-review (28 January-4 February 2020)**
-* Implementation: Prototype in master behind `-Xfrontend -enable-experimental-concise-pound-file`; revisions in [apple/swift#29412](https://github.com/apple/swift/pull/29412)
+* Status: **Implemented (Swift 5.8)**
+* Upcoming Feature Flag: `ConciseMagicFile`
+* Decision Notes: [Review #1](https://forums.swift.org/t/se-0274-concise-magic-file-names/32373/50), [Review #2](https://forums.swift.org/t/re-review-se-0274-concise-magic-file-names/33171/11), [Additional Commentary](https://forums.swift.org/t/revisiting-the-source-compatibility-impact-of-se-0274-concise-magic-file-names/37720)
+* Next Proposal: [SE-0285](0285-ease-pound-file-transition.md)
## Introduction
@@ -49,7 +50,7 @@ For `#file`'s most important use case, it seems like the current string computed
We propose changing the string that `#file` evaluates to—instead of evaluating to the full path, it will now have the format `/`. For those applications which still need a full path, we will provide a new magic identifier, `#filePath`. Both of these features will otherwise behave the same as the old `#file`, including capturing the call site location when used in default arguments. The standard library's assertion and error functions will continue to use `#file`.
-With this proposal, a file at `/Users/brent/Desktop/0274-magic-file.swift` in a module named `MagicFile` with this content:
+With this proposal, a file at `/Users/becca/Desktop/0274-magic-file.swift` in a module named `MagicFile` with this content:
```swift
print(#file)
@@ -61,7 +62,7 @@ Would produce this output:
```text
MagicFile/0274-magic-file.swift
-/Users/brent/Desktop/0274-magic-file.swift
+/Users/becca/Desktop/0274-magic-file.swift
Fatal error: Something bad happened!: file MagicFile/0274-magic-file.swift, line 3
```
@@ -153,6 +154,8 @@ These are implemented in the unmerged [apple/swift#29412](https://github.com/app
All existing source code will continue to compile with this change, and `#file`'s documentation never specified precisely what its contents were; in one of the pitch threads, [Ben Cohen](https://forums.swift.org/t/concise-magic-file-names/31297/19) said that this is sufficient to satisfy Swift's source compatibility requirements. However, the proposal *will* cause behavior to change in existing code, and in some cases it will change in ways that cause existing code to behave incorrectly when run. Code that is adversely affected by this change can access the previous behavior by using `#filePath` instead of `#file`.
+The change to the behavior of `#file` was deferred to the next major language version (Swift 6). However, it can be enabled with the [upcoming feature flag](0362-piecemeal-future-features.md) `ConciseMagicFile`.
+
## Effect on ABI stability
None. `#file` is a compile-time feature; existing binaries will continue to work as they did before.
diff --git a/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md b/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md
index 0129be339a..c2423c71e4 100644
--- a/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md
+++ b/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md
@@ -107,10 +107,10 @@ It was considered to extend the grammars for methods declaration only, this was
It was suggested, as an alternative, for the testing method names use case to add a method attribute:
```
@test("test validation should succeed when input is less than ten")
-func testValidationShouldSuccedWhenInputIsLessThanTen() {}
+func testValidationShouldSucceedWhenInputIsLessThanTen() {}
```
It was not considered a valid option for few reasons:
-* it introduces information redudancy
+* it introduces information redundancy
* it is not applicable for the rest of the issues mentioned above
* adding a new attribute would likely to introduce more complexity to the compiler and to the test runner
diff --git a/proposals/0276-multi-pattern-catch-clauses.md b/proposals/0276-multi-pattern-catch-clauses.md
index 7c2c02f174..48bb923696 100644
--- a/proposals/0276-multi-pattern-catch-clauses.md
+++ b/proposals/0276-multi-pattern-catch-clauses.md
@@ -3,7 +3,7 @@
* Proposal: [SE-0276](0276-multi-pattern-catch-clauses.md)
* Author: [Owen Voorhees](https://github.com/owenv)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
-* Status: **Accepted**
+* Status: **Implemented (Swift 5.3)**
* Implementation: [apple/swift#27776](https://github.com/apple/swift/pull/27776)
* Decision Notes: [Review](https://forums.swift.org/t/accepted-se-0276-multi-pattern-catch-clauses/33220)
diff --git a/proposals/0277-float16.md b/proposals/0277-float16.md
new file mode 100644
index 0000000000..83e40bf265
--- /dev/null
+++ b/proposals/0277-float16.md
@@ -0,0 +1,126 @@
+# Float16
+
+* Proposal: [SE-0277](0277-float16.md)
+* Author: [Stephen Canon](https://github.com/stephentyrone)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift#30130](https://github.com/apple/swift/pull/30130)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0277-float16/34121)
+
+## Introduction
+
+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.
+
+* Old pitch thread: [Add `Float16`](https://forums.swift.org/t/add-float16/19370).
+* New pitch thread: [Add Float16](https://forums.swift.org/t/add-float16/33019)
+
+## Motivation
+
+The last decade has seen a dramatic increase in the use of floating-point types smaller
+than (32-bit) `Float`. The most widely implemented is `Float16`, which is used
+extensively on mobile GPUs for computation, as a pixel format for HDR images, and as
+a compressed format for weights in ML applications.
+
+Introducing the type to Swift is especially important for interoperability with shader-language
+programs; users frequently need to set up data structures on the CPU to
+pass to their GPU programs. Without the type available in Swift, they are forced to use
+unsafe mechanisms to create these structures.
+
+In addition, C APIs that use these types simply cannot be imported, making them
+unavailable in Swift.
+
+## Proposed solution
+
+Add `Float16` to the standard library.
+
+## Detailed design
+
+There is shockingly little to say here. We will add:
+```
+@frozen
+struct Float16: BinaryFloatingPoint, SIMDScalar, CustomStringConvertible { }
+```
+The entire API falls out from that, with no additional surface outside that provided by those
+protocols. `Float16` will provide exactly the operations that `Float` and `Double` and `Float80`
+do for their conformance to these protocols.
+
+We also need to ensure that the parameter passing conventions followed by the compiler
+for `Float16` are what we want; these values should be passed and returned in the
+floating-point registers, and vectors should be passed and returned in SIMD registers.
+
+On platforms that do not have native arithmetic support, we will convert `Float16` to
+`Float` and use the hardware support for `Float` to perform the operation. This is
+correctly-rounded for every operation except fused multiply-add. A software sequence
+will be used to emulate fused multiply-add in these cases (the easiest option is to convert
+to `Double`, but other options may be more efficient on some architectures, especially
+for vectors).
+
+## Source compatibility
+
+N/A
+
+## Effect on ABI stability
+
+There is no change to existing ABI. We will be introducing a new type, which will have
+appropriate availability annotations.
+
+## Effect on API resilience
+
+The `Float16` type would become part of the public API. It will be `@frozen`, so no
+further changes will be possible, but its API and layout are entirely constrained by
+IEEE 754 and conformance to `BinaryFloatingPoint`, so there are no alternatives
+possible anyway.
+
+## Alternatives considered
+
+Q: Why isn't it called `Half`?
+
+A: `FloatN` is the more consistent pattern. Swift already has `Float32`,
+`Float64` and `Float80` (with `Float` and `Double` as alternative spellings of `Float32`
+and `Float64`, respectively). At some future point we will add `Float128`. Plus, the C
+language type that this will bridge to is named `_Float16`.
+
+`Half` is not completely outrageous as an alias, but we shouldn't add aliases unless
+there's a really compelling reason.
+
+During the pitch phase, feedback was fairly overwhelmingly in favor of `Float16`, though
+there are a few people who would like to have both names available. Unless significantly
+more people come forward, however, we should make the "opinionated" choice to have a single
+name for the type. An alias could always be added with a subsequent minor proposal if
+necessary.
+
+Q: What about ARM's ["alternative half precision"](https://en.wikipedia.org/wiki/Half-precision_floating-point_format#ARM_alternative_half-precision)?
+What about [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)?
+
+A: Alternative half-precision is no longer supported; ARMv8.2-FP16 only uses the IEEE 754
+encoding. Bfloat is something that we should *also* support eventually, but it's a separate
+proposal. and we should wait a little while before doing it. Conformance to IEEE 754 fully
+defines the semantics of `Float16` (and several hardware vendors, including Apple have
+been shipping processors that implement those semantics for a few years). By contrast,
+there are a few proposals for hardware that implements bfloat16; ARM and Intel designed
+different multiply-add units for it, and haven't shipped yet (and haven't defined any
+operations *other* than a non-homogeneous multiply-add). Other companies have HW in
+use, but haven't (publicly) formally specified their arithmetic. It's a moving target, and it
+would be a mistake to attempt to specify language bindings today.
+
+Q: Do we need conformance to `BinaryFloatingPoint`? What if we made it a storage-only format?
+
+A: We could make it a type that can only be used to convert to/from `Float` and `Double`,
+forcing all arithmetic to be performed in another format. However, this would mean that
+it would be much harder, in some cases, to get the same numerical result on the CPU and
+GPU (when GPU computation is performed in half-precision). It's a very nice convenience
+to be able to do a computation in the REPL and see what a GPU is going to do.
+
+Q: Why not put it in Swift Numerics?
+
+A: The biggest reason to add the type is for interoperability with C-family and GPU programs
+that want to use their analogous types. In order to maximize the support for that interoperability,
+and to get the calling conventions that we want to have in the long-run, it makes more sense to put
+this type in the standard library.
+
+Q: What about math library support?
+
+A: If this proposal is approved, I will add conformance to `Real` in Swift Numerics, providing
+the math library functions (by using the corresponding `Float` implementations initially).
diff --git a/proposals/0278-package-manager-localized-resources.md b/proposals/0278-package-manager-localized-resources.md
new file mode 100644
index 0000000000..5f253cdbf3
--- /dev/null
+++ b/proposals/0278-package-manager-localized-resources.md
@@ -0,0 +1,316 @@
+# Package Manager Localized Resources
+
+* Proposal: [SE-0278](0278-package-manager-localized-resources.md)
+* Author: [David Hart](https://github.com/hartbit)
+* Review Manager: [Boris Buegling](https://github.com/neonichu)
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift-package-manager#2535](https://github.com/apple/swift-package-manager/pull/2535),
+ [apple/swift-package-manager#2606](https://github.com/apple/swift-package-manager/pull/2606)
+
+## Introduction
+
+This proposal builds on top of the [Package Manager Resources](0271-package-manager-resources.md) proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.
+
+## Motivation
+
+The recently accepted [Package Manager Resources](0271-package-manager-resources.md) proposal allows SwiftPM users to define resources (images, data file, etc...) in their manifests and have them packaged inside a bundle to be accessible at runtime using the Foundation `Bundle` APIs. Bundles support storing different versions of resources for different localizations and can retrieve the version which makes most sense depending on the runtime environment, but SwiftPM currently offers no way to define those localized variants.
+
+While it is technically possible to benefit from localization today by setting up a resource directory structure that the `Bundle` API expects and specifying it with a `.copy` rule in the manifest (to have SwiftPM retain the structure), this comes at a cost: it bypasses any platform-custom processing that comes with `.process`, and doesn't allow SwiftPM to provide diagnostics when localized resources are mis-configured.
+
+Without a way to define localized resources, package authors are missing out on powerful Foundation APIs to have their applications, libraries and tools adapt to different regions and languages.
+
+## Goals
+
+The goals of this proposal builds on those of the [Package Manager Resources](0271-package-manager-resources.md) proposal:
+
+* Making it easy to add localized variants of resources with minimal change to the manifest.
+
+* Avoiding unintentionally copying files not intended to be localized variants into the product.
+
+* Supporting platform-specific localized resource types for packages written using specific APIs (e.g. Storyboards, XIBs, strings, and stringsdict files on Apple platforms).
+
+## Proposed Solution
+
+The proposed solution for supporting localized resources in Swift packages is to:
+
+* Add a new optional `defaultLocalization` parameter to the `Package` initializer to define the default localization for the resource bundle. The default localization will be used as a fallback when no other localization for a resource fits the runtime environment. SwiftPM will require that parameter be set if the package contains localized resources.
+
+* Require localized resources to be placed in directories named after the [IETF Language Tag](https://en.wikipedia.org/wiki/IETF_language_tag) they represent followed by an `.lproj` suffix, or in a special `Base.lproj` directory to open up future support for [Base Internationalization](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html#//apple_ref/doc/uid/10000171i-CH3-SW2) on Apple platforms. While Foundation supports several localization directories which are not valid IETF Language Tags, like `English` or `en_US`, it is recommended to use `en-US` style tags with a two-letter ISO 639-1 or three-letter ISO 639-2 language code, followed by optional region and/or dialect codes separated by a hyphen (see the [CFBundleDevelopmentRegion documentation](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundledevelopmentregion#)).
+
+* Add an optional `localization` parameter to the `Resource.process` factory function to allow declaring files outside of `.lproj` directories as localized for the default or base localization.
+
+* Have SwiftPM diagnose incoherent resource configurations. For example, if a resource has both an un-localized and a localized variant, the localized variant can never be selected by `Foundation` (see the documentation on [The Bundle Search Pattern](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/AccessingaBundlesContents/AccessingaBundlesContents.html#//apple_ref/doc/uid/10000123i-CH104-SW7)).
+
+* Have SwiftPM copy the localized resource to the resource bundle in the right locations for the `Foundation` APIs to find and use them, and generate a `Info.plist` for the resources bundle containing the `CFBundleDevelopmentRegion` key set to the `defaultLocalization`.
+
+## Detailed Design
+
+### Declaring Localized Resources
+
+The `Package` initializer in the `PackageDescription` API gains a new optional `defaultLocalization` parameter with type `LocalizationTag` and a default value of `nil`:
+
+```swift
+public init(
+ name: String,
+ defaultLocalization: LocalizationTag = nil, // New defaultLocalization parameter.
+ pkgConfig: String? = nil,
+ providers: [SystemPackageProvider]? = nil,
+ products: [Product] = [],
+ dependencies: [Dependency] = [],
+ targets: [Target] = [],
+ swiftLanguageVersions: [Int]? = nil,
+ cLanguageStandard: CLanguageStandard? = nil,
+ cxxLanguageStandard: CXXLanguageStandard? = nil
+)
+```
+`LocalizationTag` is a wrapper around a [IETF Language Tag](https://en.wikipedia.org/wiki/IETF_language_tag), with a `String` initializer and conforming to `Hashable`, `RawRepresentable`, `CustomStringConvertible` and `ExpressibleByStringLiteral`. While a `String` would suffice for now, the type allows for future expansion.
+
+```swift
+/// A wrapper around a [IETF Language Tag](https://en.wikipedia.org/wiki/IETF_language_tag).
+public struct LocalizationTag: Hashable {
+
+ /// A IETF language tag.
+ public let tag: String
+
+ /// Creates a `LocalizationTag` from its IETF string representation.
+ public init(_ tag: String) {
+ self.tag = tag
+ }
+}
+
+extension LocalizationTag: RawRepresentable, ExpressibleByStringLiteral, CustomStringConvertible {
+ // Implementation.
+}
+```
+
+To allow marking files outside of `.lproj` directories as localized, the `Resource.process` factory function gets a new optional `localization` parameter typed as an optional `LocalizationType`, an enum with two cases: `.default` for declaring a default localized variant, and `.base` for declaring a base-localized resource:
+
+```swift
+public struct Resource {
+ public enum LocalizationType {
+ case `default`
+ case base
+ }
+
+ public static func process(_ path: String, localization: LocalizationType? = nil) -> Resource
+}
+```
+
+### Localized Resource Discovery
+
+SwiftPM will only detect localized resources if they are defined with the `.process` rule. When scanning for files with that rule, SwiftPM will tag files inside directories with an `.lproj` suffix as localized variants of a resource. The name of the directory before the `.lproj` suffix identifies which localization they correspond to. For example, an `en.lproj` directory contains resources localized to English, while a `fr-CH.lproj` directory contains resources localized to French for Swiss speakers.
+
+Files in those special directories represent localized variants of a "virtual" resource with the same name in the parent directory, and the manifest must use that path to reference them. For example, the localized variants in `Resources/en.lproj/Icon.png` and `Resources/fr.lproj/Icon.png` are english and french variants of the same "virtual" resource with the `Resources/Icon.png` path, and a reference to it in the manifest would look like:
+
+```swift
+let package = Package(
+ name: "BestPackage",
+ defaultLocalization: "en",
+ targets: [
+ .target(name: "BestTarget", resources: [
+ .process("Resources/Icon.png"),
+ ])
+ ]
+)
+```
+
+To support SwiftPM clients for Apple platform-specific resources, SwiftPM will also recognize resources located in `Base.lproj` directories as resources using [Base Internationalization](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html#//apple_ref/doc/uid/10000171i-CH3-SW2) and treat them as any other localized variants.
+
+In addition to localized resources detected by scanning `.lproj` directories, SwiftPM will also take into account processed resources declared with a `localization` parameter in the manifest. This allows package authors to mark files outside of `.lproj` directories as localized, for example to keep localized and un-localized resources together. Separate post-processing done outside of SwiftPM can provide additional localizations in this case.
+
+### Validating Localized Resources
+
+SwiftPM can help package authors by diagnosing mis-configurations of localized resources and other inconsistencies that may otherwise only show up at runtime. To illustrate the diagnostics described below, we define a `Package.swift` manifest with a default localization of `"en"`, and two resource paths with the `.process` rule an one with the `.copy` rule:
+
+```swift
+let package = Package(
+ name: "BestPackage",
+ defaultLocalization: "en",
+ targets: [
+ .target(name: "BestTarget", resources: [
+ .process("Resources/Processed"),
+ .copy("Resources/Copied"),
+ ])
+ ]
+```
+
+#### Sub-directory in Localization Directory
+
+To avoid overly-complex and ambiguous resource directory structures, SwiftPM with emit an error when a localization directory in a `.process` resource path contains a sub-directory. For example, the following directory structure:
+
+```
+BestPackage
+|-- Sources
+| `-- BestTarget
+| |-- Resources
+| | |-- Processed
+| | | `-- en.lproj
+| | | `-- directory
+| | | `-- file.txt
+| | `-- Copied
+| | `-- en.lproj
+| | `-- directory
+| | `-- file.txt
+| `-- main.swift
+`-- Package.swift
+```
+
+will emit the following diagnostic:
+
+```
+error: localization directory `Resources/Processed/en.lproj` in target `BestTarget` contains sub-directories, which is forbidden
+```
+
+#### Missing Default Localized Variant
+
+When a localized resource is missing a variant for the default localization, `Foundation` may not be able to find the resource depending on the run environment. SwiftPM will emit a warning to warn against it. For example, the following directory structure:
+
+```
+BestPackage
+|-- Sources
+| `-- BestTarget
+| |-- Resources
+| | |-- Processed
+| | | `-- fr.lproj
+| | | `-- Image.png
+| | `-- Copied
+| | `-- fr.lproj
+| | `-- Image.png
+| `-- main.swift
+`-- Package.swift
+```
+
+will emit the following diagnostic:
+
+
+```
+warning: resource 'Image.png' in target 'BestTarget' is missing a localization for the default localization 'en'; the default localization is used as a fallback when no other localization matches
+```
+
+#### Un-localized and Localized Variants
+
+When there exists both an un-localized and localized variant of the same resource, SwiftPM will emit a warning to let users know that the localized variants will never be chosen at runtime, due to the search pattern of `Foundation` APIs (see the documentation on [The Bundle Search Pattern](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/AccessingaBundlesContents/AccessingaBundlesContents.html#//apple_ref/doc/uid/10000123i-CH104-SW7)). For example, the following directory structure:
+
+```
+BestPackage
+|-- Sources
+| `-- BestTarget
+| |-- Resources
+| | |-- Processed
+| | | |-- en.lproj
+| | | | `-- Image.png
+| | | `-- Image.png
+| | `-- Copied
+| | |-- en.lproj
+| | | `-- Image.png
+| | `-- Image.png
+| `-- main.swift
+`-- Package.swift
+```
+
+will emit the following diagnostic:
+
+```
+warning: resource 'Image.png' in target 'BestTarget' has both localized and un-localized variants; the localized variants will never be chosen
+```
+
+### Missing Default Localization
+
+The `defaultLocalization` property is optional and has a default value of `nil`, but its required to provide a valid `LocalizationTag` in the presence of localized resources. SwiftPM with emit an error if that is not the case. For example, the following directory structure:
+
+```
+BestPackage
+|-- Sources
+| `-- BestTarget
+| |-- Resources
+| | `-- en.lproj
+| | `-- Localizable.strings
+| `-- main.swift
+`-- Package.swift
+```
+
+with the following manifest:
+
+```swift
+let package = Package(
+ name: "BestPackage",
+ targets: [
+ .target(name: "BestTarget", resources: [
+ .process("Resources"),
+ ])
+ ]
+```
+
+will emit the following diagnostic:
+
+```
+error: missing manifest property 'defaultLocalization'; it is required in the presence of localized resources
+```
+
+#### Explicit Localization Resource in Localization Directory
+
+Explicit resource localization declarations exist to avoid placing resources in localization directories. To avoid any ambiguity, SwiftPM will emit an error when a resource with an explicit localization declaration is inside a localization directory.
+
+```
+BestPackage
+|-- Sources
+| `-- BestTarget
+| |-- Resources
+| | `-- en.lproj
+| | `-- Storyboard.storyboard
+| `-- main.swift
+`-- Package.swift
+```
+
+with the following manifest:
+
+```swift
+let package = Package(
+ name: "BestPackage",
+ defaultLocalization: "en",
+ targets: [
+ .target(name: "BestTarget", resources: [
+ .process("Resources", localization: .base),
+ ])
+ ]
+```
+
+will emit the following diagnostic:
+
+```
+error: resource 'Storyboard.storyboard' in target 'BestTarget' is in a localization directory and has an explicit localization declaration; choose one or the other to avoid any ambiguity
+```
+
+### Resource Bundle Generation
+
+SwiftPM will copy localized resources into the correct locations of the resources bundle for them to be picked up by Foundation. It will also generate a `Info.plist` for that bundle with the `CFBundleDevelopmentRegion` value declared in the manifest:
+
+```xml
+
+
+
+
+ CFBundleDevelopmentRegion
+ fr-CH
+
+
+```
+
+### Runtime Access
+
+The Foundation APIs already used to load resources will automatically pick up the correct localization:
+
+```swift
+// Get path to a file, which can be localized.
+let path = Bundle.module.path(forResource: "TOC", ofType: "md")
+
+// Load an image from the bundle, which can be localized.
+let image = UIImage(named: "Sign", in: .module, with: nil)
+```
+
+And other APIs will now work as expected on all platforms Foundation is supported on:
+
+```swift
+// Get localization out of strings files.
+var localizedGreeting = NSLocalizedString("greeting", bundle: .module)
+```
diff --git a/proposals/0279-multiple-trailing-closures.md b/proposals/0279-multiple-trailing-closures.md
new file mode 100644
index 0000000000..0f1b03e4f5
--- /dev/null
+++ b/proposals/0279-multiple-trailing-closures.md
@@ -0,0 +1,385 @@
+# Multiple Trailing Closures
+
+* Proposal: [SE-0279](0279-multiple-trailing-closures.md)
+* Authors: [Kyle Macomber](https://github.com/kylemacomber), [Pavel Yaskevich](https://github.com/xedin), [Doug Gregor](https://github.com/douggregor), [John McCall](https://github.com/rjmccall)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 5.3)**
+* Previous Revisions: [1st](https://github.com/swiftlang/swift-evolution/blob/d923209a05c3c38c8b735510cf1525d27ed4bd14/proposals/0279-multiple-trailing-closures.md)
+* Reviews: [1st](https://forums.swift.org/t/se-0279-multiple-trailing-closures/34255),
+ [2nd](https://forums.swift.org/t/se-0279-multiple-trailing-closures-amended/35435),
+ [3rd](https://forums.swift.org/t/accepted-se-0279-multiple-trailing-closures/36141)
+* Implementation: [apple/swift#31052](https://github.com/apple/swift/pull/31052)
+
+## Motivation
+
+Since its inception, Swift has supported *trailing closure* syntax: a bit of syntactic sugar that lets you "pop" the final argument to a function out of the parentheses when it's a closure.
+
+This example uses [`UIView.animate(withDuration:animations:)`](https://developer.apple.com/documentation/uikit/uiview/1622418-animate) to fade out a view:
+
+```swift
+// Without trailing closure:
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+})
+// With trailing closure:
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+}
+```
+
+Trailing closure syntax has proven to be very popular, and it's not hard to guess why. Especially when an API is crafted with trailing closure syntax in mind, the call site is *easier to read*: it is more concise and less nested, without loss of clarity.
+
+However, the restriction of trailing closure syntax to *only the final closure* has limited its applicability. This limitation was noticed [very early on in Swift's lifetime](https://www.natashatherobot.com/swift-trailing-closure-syntax/) as "the" problem with trailing closure syntax.
+
+Consider using [`UIView.animate(withDuration:animations:completion:)`](https://developer.apple.com/documentation/uikit/uiview/1622515-animate) to remove the view once it has finished fading out:
+
+```swift
+// Without trailing closure:
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+}, completion: { _ in
+ self.view.removeFromSuperview()
+})
+// With trailing closure
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+}) { _ in
+ self.view.removeFromSuperview()
+}
+```
+
+In this case, the trailing closure syntax is *harder to read*: the role of the trailing closure is unclear, the first closure remains nested, and something about the asymmetry is unsettling.
+
+Concerns about call-site confusion have led Swift style guides to include rules that prohibit the use of trailing closure syntax when a function call has multiple closure arguments ([1](https://google.github.io/swift/#trailing-closures), [2](https://rules.sonarsource.com/swift/RSPEC-2958)).
+
+As a result, if we ever need to append an additional closure argument to a function, many of us find ourselves having to rejigger our code more than may seem necessary:
+
+```swift
+// Single closure argument -> trailing closure
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+}
+// Multiple closure arguments -> no trailing closure
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+}, completion: { _ in
+ self.view.removeFromSuperview()
+})
+```
+
+## Proposed Solution
+
+This proposal extends trailing closure syntax to allow additional *labeled* closures to follow the initial unlabeled closure:
+
+```swift
+// Single trailing closure argument
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+}
+// Multiple trailing closure arguments
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+} completion: { _ in
+ self.view.removeFromSuperview()
+}
+```
+
+This extends the concision and denesting of trailing closure syntax to function calls with multiple closures arguments. And there's no rejiggering required to append an additional trailing closure argument!
+Informally, the new syntax rules are:
+
+* The first trailing closure drops its argument label (like today).
+* Subsequent trailing closures require argument labels.
+
+These rules seem to work well in practice, because functions with multiple closure arguments tend to have one that is more primary. Often any additional closure arguments are optional (via default parameter values or overloading), in order to provide progressive disclosure:
+
+
+1. We've already seen UIKit's [`UIView.animate(withDuration:animations:)`](https://developer.apple.com/documentation/uikit/uiview/1622418-animate) and [`UIView.animate(withDuration:animations:completion:)`](https://developer.apple.com/documentation/uikit/uiview/1622515-animate) functions.
+
+2. Consider Combine's [sink](https://developer.apple.com/documentation/combine/publisher/3343978-sink) operator, which today contorts itself to the existing trailing closure rules:
+
+ ```swift
+ ipAddressPublisher
+ .sink { identity in
+ self.hostnames.insert(identity.hostname!)
+ }
+
+ ipAddressPublisher
+ .sink(receiveCompletion: { completion in
+ // handle error
+ }) { identity in
+ self.hostnames.insert(identity.hostname!)
+ }
+ ```
+
+ ... but could be re-worked in light of multiple trailing closure syntax:
+
+ ```swift
+ ipAddressPublisher
+ .sink { identity in
+ self.hostnames.insert(identity.hostname!)
+ }
+
+ ipAddressPublisher
+ .sink { identity in
+ self.hostnames.insert(identity.hostname!)
+ } receiveCompletion: { completion in
+ // handle error
+ }
+ ```
+
+3. Consider SwiftUI's [Section](https://developer.apple.com/documentation/swiftui/section) view, which today avoids using `@ViewBuilder` closures for its optional header and footer:
+
+ ```swift
+ Section {
+ // content
+ }
+ Section(header: ...) {
+ // content
+ }
+ Section(footer: ...) {
+ // content
+ }
+ Section(
+ header: ...,
+ footer: ...
+ ) {
+ // content
+ }
+ ```
+
+ ... but could be re-worked in light of multiple trailing closure syntax:
+
+ ```swift
+ Section {
+ // content
+ }
+ Section {
+ // content
+ } header: {
+ ...
+ }
+ Section {
+ // content
+ } footer: {
+ ...
+ }
+ Section {
+ // content
+ } header: {
+ ...
+ } footer: {
+ ...
+ }
+ ```
+
+When using multiple trailing closure syntax, these APIs are all [clear at the point of use](https://swift.org/documentation/api-design-guidelines/#fundamentals), without the need to label the first trailing closure.
+
+If labelling the first trailing closure were allowed, users would have to evaluate whether to include the label on a case by case basis, which would inevitably lead to linter and style guide rules to prohibit it. So, in conjunction with the new syntax rules, we propose an amendment to the [API Design Guidelines](https://swift.org/documentation/api-design-guidelines):
+
+> Name functions assuming that the argument label of the first trailing closure will be dropped. Include meaningful argument labels for all subsequent trailing closures.
+
+## Detailed Design
+
+The grammar is modified as follows to accommodate labeled trailing closures following an unlabeled trailing closure:
+
+```
+expr-trailing-closure:
+ expr-postfix(trailing-closure) trailing-closures
+
+trailing-closures:
+ expr-closure
+ trailing-closures (identifier|keyword|'_') ':' expr-closure
+```
+
+This introduces a zero-lookahead ambiguity between the start of a labeled trailing closure and the start of either a new expression, a labeled statement, or a `default:` label followed by `'{'`. The first two ambiguities can be resolved by looking forward at most two tokens, because `(identifier|keyword|'_') ':'` can never start an expression, only a labeled statement, and the statement in a labeled statement can never start with `'{'` while `expr-closure` must start with it. The ambiguity with `default:` can be resolved by not allowing the unescaped `default` keyword as a label in this syntax; it can still be used if necessary by escaping it (i.e. `` `default`: ``). Source compatibility requires the existing use of `default:` to be preferred, and it's better to do this uniformly (even if the syntax does not appear in a `switch`) in order to discourage the use of `default` as a trailing-closure label in APIs, rather than leaving a trap in the language if an API like that is used within a `switch`.
+
+The labeled trailing closures are associated with the base expression in the same way as the unlabeled trailing closure is today:
+
+* if the base expression is a call, they are added as extra arguments to that call;
+* if the base expression is a subscript, they are added as extra index arguments to that subscript,
+* otherwise, an implicit call of the base expression is created using only the trailing closures as arguments.
+
+The existing trailing-closure feature requires special treatment of the trailing-closure argument by the type checker because of the special power of label omission: the trailing closure can be passed to a parameter that would ordinarily require an argument label. Currently, the special treatment is specific to the final argument. Because this proposal still has an unlabeled trailing-closure argument, we have to generalize that treatment to allow label omission at an intermediate argument.
+
+Note that labeled trailing closures are required to match labels with a parameter. A labeled trailing closure can use the special label `_` to indicate that it matches an unlabeled parameter, but this *only* matches an unlabeled parameter; it does not have the special label-omission powers of the initial unlabeled trailing closure. For example:
+
+```swift
+func pointFromClosures(
+ x: () -> Int,
+ _ y: () -> Int
+) -> (Int, Int) {
+ (x(), y())
+}
+pointFromClosures { 10 } _: { 20 } // Ok
+
+func performAsync(
+ action: @escaping () -> Void,
+ completionOnMainThread: @escaping () -> Void
+) {
+ ...
+}
+performAsync {
+ // some action
+} _: { // Not okay: must use completionOnMainThread:
+ window.exit()
+}
+```
+
+In the current representation, the AST maintains a flag indicating whether the last argument was a trailing closure. This is no longer sufficient, and instead the AST must maintain the exact position of the first trailing closure in the argument list.
+
+The current type-checking rule for trailing closures performs a limited backwards scan through the parameters looking for a parameter that is compatible with a trailing closure. The proposed type-checking rule builds on this while seeking to degenerate to the old behavior when there are no labeled trailing closures. This is done by performing a backwards scan through the parameters to bind all the labeled trailing closures to parameters using label-matching, then doing the current limited scan for the unlabeled trailing closure starting from the last labeled parameter that was matched.
+
+For example, given this function:
+
+```swift
+func when(
+ _ condition: @autoclosure () -> Bool,
+ then: () -> T,
+ `else`: () -> T
+) -> T {
+ condition() ? then() : `else`()
+}
+```
+
+The following call using the new syntax:
+
+```swift
+when(2 < 3) {
+ print("then")
+} else: {
+ print("else")
+}
+```
+
+is equivalent to:
+
+```swift
+when(2 < 3, then: { print("then") }, else: { print("else") })
+```
+
+It's important to note that the handling of default arguments in relation to trailing closures is maintained as-is. For example:
+
+```swift
+func foo(a: () -> Int = { 42 }, b: Any? = nil) {}
+
+foo {
+ 42
+}
+```
+
+Although trailing closure matches parameter for `a:` by type, existing trailing closure behavior would match trailing closure argument to parameter labeled as `b:`, which means that previous call to foo is equivalent to:
+
+```swift
+foo(b: { 42 })
+```
+
+Now let's add one more parameter to foo to see how this applies to the new multiple trailing closures syntax:
+
+```swift
+func foo(a: () -> Int = { 42 }, b: Any? = nil, c: () -> Void) {}
+
+foo {
+ 42
+} c: {
+ ...
+}
+```
+
+Since the new type-checking rule dictates a backwards scan starting for the last (labeled) trailing closure before attempting to match an unlabeled argument, this call is equivalent to a following "old" syntax:
+
+```swift
+foo(b: { 42 }, c: { ... })
+```
+
+This shows that unlabeled trailing closure matching behaves exactly the same way in both scenarios.
+
+There are reasonable arguments against the backwards-scan design for type-checking trailing closures. Perhaps the strongest argument is that this interaction with default arguments is unintuitive and limiting. For example, it is natural to want to take a primary, required closure, followed by some optional closures:
+
+```swift
+func resolve(
+ id: UUID,
+ action: (Object) -> Void,
+ completion: (() -> Void)? = nil,
+ onError: ((Error) -> Void)? = nil
+) {
+ ...
+}
+```
+
+Under the proposed type-checking rule, code like the following will not type-check as expected:
+
+```swift
+resolve(id: paulID) { paul in
+ // do something with object
+} onError: { error in
+ // handle error
+}
+```
+
+It is tempting to try to take advantage of the introduction of this new syntax to use a better type-checking rule that would handle this correctly. This would help in some cases. However, unfortunately, when the programmer omits both of the optional closures, they’re no longer using this new syntax, because they’ve dropped back to the existing trailing-closure case:
+
+```swift
+resolve(id: paulID) { paul in
+ // do something with object
+}
+```
+
+The behavior of this call can’t be changed without potentially breaking source compatibility. That might be worthwhile to do in order to enable these sorts of APIs and get more consistent type-checking behavior for trailing closures; however, it will need its own proposal, and it will only be feasible under a new source-compatibility mode. We recommend considering this for Swift 6. In the meantime, library designers will have to use overloading to get this effect instead of default arguments.
+
+## Alternatives Considered
+
+### Trailing Block of Closures
+
+Multiple trailing closures could alternatively be specified within a trailing block, with each trailing closure indicated by an argument label:
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ animations: {
+ self.view.alpha = 0
+ }
+ completion: { _ in
+ self.view.removeFromSuperview()
+ }
+}
+```
+
+While this syntax is clear at the point of use, pleasant to read, and provides contextual cues by separating the trailing closures from the rest of the arguments, it risks evolving into an alternative calling syntax. The proposed syntax is more concise and less nested, without loss of clarity:
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+} completion: { _ in
+ self.view.removeFromSuperview()
+}
+```
+
+### Optionally Labeled First Trailing Closure
+
+The proposed syntax could be extended to allow users to optionally label the first trailing closure:
+
+```swift
+ipAddressPublisher
+ .sink receiveCompletion: { completion in
+ // handle error
+ }
+```
+
+This would allow the user to disambiguate when the backwards-scan would have otherwise resolved differently, in this case for the declaration:
+
+```swift
+public func sink(
+ receiveCompletion: ((Subscribers.Completion) -> Void)? = nil,
+ receiveValue: ((Output) -> Void)? = nil
+) -> Subscribers.Sink
+```
+
+However, it shouldn’t be used to disambiguate for fellow humans. Recall: API authors should be naming functions assuming that the argument label of the first trailing closure will be dropped. Swift users aren’t used to seeing function names and argument labels juxtaposed without parenthesis. Many find this spelling unsettling.
+
+Improving the type-checking rule, as described in Detailed Design, is a more promising avenue for addressing this use case. In the meantime, users that find themselves in this situation can use the existing syntax:
+
+```swift
+ipAddressPublisher
+ .sink(receiveCompletion: { completion in
+ // handle error
+ })
+```
diff --git a/proposals/0280-enum-cases-as-protocol-witnesses.md b/proposals/0280-enum-cases-as-protocol-witnesses.md
new file mode 100644
index 0000000000..b837d99485
--- /dev/null
+++ b/proposals/0280-enum-cases-as-protocol-witnesses.md
@@ -0,0 +1,189 @@
+# Enum cases as protocol witnesses
+
+* Proposal: [SE-0280](0280-enum-cases-as-protocol-witnesses.md)
+* Author: [Suyash Srijan](https://github.com/theblixguy)
+* Review Manager: [John McCall](https://github.com/rjmccall)
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift#28916](https://github.com/apple/swift/pull/28916)
+* Bug: [SR-3170](https://bugs.swift.org/browse/SR-3170)
+* Toolchain: [macOS](https://ci.swift.org/job/swift-PR-toolchain-osx/477/artifact/branch-master/swift-PR-28916-477-osx.tar.gz) & [Linux](https://ci.swift.org/job/swift-PR-toolchain-Linux/346/artifact/branch-master/swift-PR-28916-346-ubuntu16.04.tar.gz)
+* Review: ([1](https://forums.swift.org/t/se-0280-enum-cases-as-protocol-witnesses/34257)) ([Acceptance](https://forums.swift.org/t/acceepted-se-0280-enum-cases-as-protocol-witnesses/34850))
+
+## Introduction
+
+The aim of this proposal is to lift an existing restriction, which is that enum cases cannot participate in protocol witness matching.
+
+Swift-evolution thread: [Enum cases as protocol witnesses](https://forums.swift.org/t/enum-cases-as-protocol-witnesses/32753)
+
+## Motivation
+
+Currently, Swift has a very restrictive protocol witness matching model where a protocol witness has to match _exactly_ with the requirement, with some exceptions (see [Protocol Witness Matching Manifesto](https://forums.swift.org/t/protocol-witness-matching-mini-manifesto/32752)).
+
+For example, if one writes a protocol with static requirements:
+
+```swift
+protocol DecodingError {
+ static var fileCorrupted: Self { get }
+ static func keyNotFound(_ key: String) -> Self
+}
+```
+
+and attempts to conform an enum to it, then writing a case with the same name (and arguments) is not considered a match:
+
+```swift
+enum JSONDecodingError: DecodingError {
+ case fileCorrupted // error, because it is not a match
+ case keyNotFound(_ key: String) // error, because it is not a match
+}
+```
+
+This is quite surprising, because even though cases are not _written_ as a `static var` or `static func`, they do _behave_ like one both syntactically and semantically throughout the language. For example:
+
+```swift
+enum Foo {
+ case bar(_ value: Int)
+ case baz
+}
+
+let f = Foo.bar // `f` is a function of type (Int) -> Foo
+let bar = f(2) // Returns Foo
+let baz = Foo.baz // Returns Foo
+```
+
+is the same as:
+
+```swift
+struct Foo {
+ static func bar(_ value: Int) -> Self { ... }
+ static var baz: Self { ... }
+}
+
+let f = Foo.bar // `f` is a function of type (Int) -> Foo
+let bar = f(2) // Returns Foo
+let baz = Foo.baz // Returns Foo
+```
+
+Such "spelling" exceptions exist when matching other kinds of requirements as well, for example:
+
+```swift
+protocol Foo {
+ var somePropertyA: Self { get }
+}
+
+struct ImplementsFoo: Foo {
+ // This can be a 'let' because even though the
+ // keywords don't match, and a variable and a
+ // constant are two different things, the
+ // *semantics* of 'var ... { get }' and 'let'
+ // do match.
+ let somePropertyA: Self
+ // and you can write it as a 'var' if you want
+ // and still keep the semantics the same.
+ var somePropertyA: Self
+}
+```
+
+Now, because enum cases are not considered as a "witness" for static protocol requirements, one has to provide a manual implementation instead:
+
+```swift
+enum JSONDecodingError: DecodingError {
+ case _fileCorrupted
+ case _keyNotFound(_ key: String)
+ static var fileCorrupted: Self { return ._fileCorrupted }
+ static func keyNotFound(_ key: String) -> Self {
+ return ._keyNotFound(key)
+ }
+}
+```
+
+This leads to some rather unfortunate consequences:
+
+1. The ability to write a case with the same name as the requirement is lost. Now, you can rename the case to something different, but it might not always be ideal, especially because naming things right is a really hard problem. In most cases, you expect the case to be named the same as the requirement.
+2. The namespace of the enum is now polluted with both cases and requirements (for example, in the snippet above we have `_fileCorrupted` and `fileCorrupted`), which can be confusing during code completion.
+3. There's extra code that now has to be maintained and which arguably should not exist in the first place.
+
+In almost every corner of the language, enum cases and static properties/functions are indistinguishable from each other, *except* when it comes to matching protocol requirements, which is very inconsistent, so it is not unreasonable to think of a enum case without associated values as a `static`, get-only property that returns `Self` or an enum case with associated values as a `static` function (with arguments) that returns `Self`.
+
+Lifting this restriction can also lead to other improvements, for example, one can conform `DispatchTimeInterval` directly to Combine's `SchedulerTypeIntervalConvertible` instead of having to go through a much more complicated type like `DispatchQueue.SchedulerTimeType.Stride`:
+
+```swift
+extension DispatchTimeInterval: SchedulerTimeIntervalConvertible {
+ public static func seconds(_ s: Double) -> Self {
+ return DispatchTimeInterval.seconds(Int((s * 1000000000.0).rounded()))
+ }
+ // Remaining requirements already satisfied by cases
+}
+```
+
+## Proposed Solution
+
+The current restriction is lifted and the compiler allows a static protocol requirement to be witnessed by an enum case, under the following rules:
+
+1. A static, get-only protocol requirement having an enum type or `Self` type can be witnessed by an enum case with no associated values.
+2. A static function requirement with arguments and returning an enum type or `Self` type can be witnessed by an enum case with associated values having the same argument list as the function's.
+
+This means the example from the motivation section will successfully compile:
+
+```swift
+enum JSONDecodingError: DecodingError {
+ case fileCorrupted // okay
+ case keyNotFound(_ key: String) // okay
+}
+```
+
+This also means the mental model of an enum case will now be _more_ consistent with static properties/methods and an inconsistency in the language will be removed.
+
+You will still be able to implement the requirement manually if you want and code that currently compiles today (with the manual implementation) will continue to compile. However, you will now have the option to let the case satisfy the requirement directly.
+
+Here are a few more examples that demonstrate how cases will be matched with the requirements:
+
+```swift
+protocol Foo {
+ static var zero: FooEnum { get }
+ static var one: Self { get }
+ static func two(arg: Int) -> FooEnum
+ static func three(_ arg: Int) -> Self
+ static func four(_ arg: String) -> Self
+ static var five: Self { get }
+ static func six(_: Int) -> Self
+ static func seven(_ arg: Int) -> Self
+ static func eight() -> Self
+}
+
+enum FooEnum: Foo {
+ case zero // okay
+ case one // okay
+ case two(arg: Int) // okay
+ case three(_ arg: Int) // okay
+ case four(arg: String) // not a match
+ case five(arg: Int) // not a match
+ case six(Int) // okay
+ case seven(Int) // okay
+ case eight // not a match
+}
+```
+
+The last one is intentional - there is no way to declare a `case eight()` today (and even when you could in the past, it actually had a different type). In this case, the requirement `static func eight()` can in fact be better expressed as a `static var eight`. In the future, this limitation may be lifted when other kinds of witness matching is considered.
+
+## Source compatibility
+
+This does not break source compatibility since it's a strictly additive change and allows code that previously did not compile to now compile and run successfully.
+
+## Effect on ABI stability
+
+This does not affect the ABI and does not require new runtime support.
+
+## Effect on API resilience
+
+Switching between enum cases and static properties/methods is not a resilient change due to differences in ABI and mangling. Doing so will break binary compatibility, or source compatibility if clients are pattern matching on the cases for example.
+
+
+## Alternatives considered
+
+- Allow protocol requirements to be declared as `case` instead of `static var` or `static func` - the obvious downside of doing this would be that only enums would be able to adopt such a protocol, which would be unreasonably restrictive because other types like classes and structs having satisfying witnesses would no longer be able to adopt such a protocol.
+- Only allow enum cases without associated values to participate out of the box. Ones with associated values will be disallowed unless explicitly marked with a specific annotation to allow them to be used as "factories". It seems unnecessarily restrictive to impose another syntactic barrier, one which does not exist in other types. The semantics of a protocol requirement is up to the author to document and for clients to read and verify before implementing, so adding another annotation does not provide any language improvements.
+- Leave the existing behaviour as-is.
+
+## Future directions
+
+We can allow for more kinds of witness matching, as described in the [Protocol Witness Matching Manifesto](https://forums.swift.org/t/protocol-witness-matching-mini-manifesto/32752), such as subtyping and default arguments.
diff --git a/proposals/0281-main-attribute.md b/proposals/0281-main-attribute.md
new file mode 100644
index 0000000000..204ff7e2ba
--- /dev/null
+++ b/proposals/0281-main-attribute.md
@@ -0,0 +1,208 @@
+# `@main`: Type-Based Program Entry Points
+
+* Proposal: [SE-0281](0281-main-attribute.md)
+* Authors: [Nate Cook](https://github.com/natecook1000), [Nate Chandler](https://github.com/nate-chandler), [Matt Ricketson](https://github.com/ricketson)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Status: **Implemented (Swift 5.3)**
+* Implementation: [apple/swift#30693](https://github.com/apple/swift/pull/30693)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0281-main-type-based-program-entry-points/35400)
+
+
+## Introduction
+
+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.
+
+Related forum threads:
+
+- [Initial pitch](https://forums.swift.org/t/main-type-based-program-execution/34624)
+- [Control of Swift Entry Point](https://forums.swift.org/t/control-of-swift-entry-point/25069)
+
+## Motivation
+
+Swift programs start execution at the beginning of a file. This works great for procedural code, and allows simple Swift programs to be as short as a single line, with no special syntax required.
+
+```swift
+// A self-contained Swift program:
+print("Hello, world!")
+```
+
+However, not all kinds of programs naturally fit into this model. For example, a user-facing app launches and runs until it is quit. User interface frameworks like UIKit and AppKit take care of the complexities of launching an application, providing high-level API hooks for defining app behavior. A developer using these frameworks typically does not care about nor interact with the literal starting point of their app’s execution.
+
+In order to resolve these two models, apps need a small amount of “boot-loading” code to kick off the framework’s preferred execution entry point. Ever since its initial release, Swift has provided the domain-specific attributes `@UIApplicationMain` and `@NSApplicationMain` to smooth over this startup process for developers of UIKit and AppKit applications.
+
+Instead of these hard-coded, framework-specific attributes, it would be ideal for Swift to offer a more general purpose and lightweight mechanism for delegating a program’s entry point to a designated type. A type-based approach to program execution fits within Swift's general pattern of solving problems through the type system and allows frameworks to use standard language features to provide clean, simple entry point APIs.
+
+## Proposed solution
+
+The Swift compiler will recognize a type annotated with the `@main` attribute as providing the entry point for a program. Types marked with `@main` have a single implicit requirement: declaring a static `main()` method. This `main()` method will typically be provided by libraries or frameworks, so that the author of a Swift program will only need to use the `@main` attribute to indicate the correct starting point.
+
+When the program starts, the static `main()` method is called on the type marked with `@main`. For example, this code:
+
+```swift
+// In a framework:
+public protocol ApplicationRoot {
+ // ...
+}
+extension ApplicationRoot {
+ public static func main() {
+ // ...
+ }
+}
+
+// In MyProgram.swift:
+@main
+struct MyProgram: ApplicationRoot {
+ // ...
+}
+```
+
+is equivalent to this code:
+
+```swift
+// In a framework:
+public protocol ApplicationRoot {
+ // ...
+}
+extension ApplicationRoot {
+ public static func main() {
+ // ...
+ }
+}
+
+// In MyProgram.swift:
+struct MyProgram: ApplicationRoot {
+ // ...
+}
+
+// In 'main.swift':
+MyProgram.main()
+```
+
+Since `main()` is a regular static method, it can be supplied by a protocol as an extension method or by a base class. This allows frameworks to easily define custom entry point behavior without additional language features.
+
+For example, the `ArgumentParser` library offers a `ParsableCommand` protocol that provides a default implementation for `main():`
+
+```swift
+// In ArgumentParser:
+public protocol ParsableCommand {
+ // Other requirements
+}
+
+extension ParsableCommand {
+ static func main() {
+ // Parses the command-line arguments and then
+ // creates and runs the selected command.
+ }
+}
+```
+
+The `@main` attribute would allow clients to focus on just the requirements of their command-line tool, rather than how to launch its execution:
+
+```swift
+@main
+struct Math: ParsableCommand {
+ @Argument(help: "A group of integers to operate on.")
+ var values: [Int]
+
+ func run() throws {
+ let result = values.reduce(0, +)
+ print(result)
+ }
+}
+```
+
+Likewise, UIKit and AppKit could add the static `main()` method to the `UIApplicationDelegate` and `NSApplicationDelegate` protocols, allowing authors to use the single `@main` attribute no matter the user interface framework, and allowing for the deprecation of the special-purpose attributes. (Note: These changes are not a part of this proposal.)
+
+## Detailed design
+
+The compiler will ensure that the author of a program only specifies one entry point: either a single, non-generic type designated with the `@main` attribute *or* a single `main.swift` file. The type designated as the entry point with `@main` can be defined in any of a module's source files. `@UIApplicationMain` and `@NSApplicationMain` will be counted the same way as the `@main` attribute when guaranteeing the uniqueness of a program's entry point.
+
+A `main.swift` file is always considered to be an entry point, even if it has no top-level code. Because of this, placing the `@main`-designated type in a `main.swift` file is an error.
+
+`@main` can be applied to either a type declaration or to an extension of an existing type. The `@main`-designated type can be declared in the application target or in an imported module. `@main` can be applied to the base type of a class hierarchy, but is not inherited — only the specific annotated type is treated as the entry point.
+
+The rules for satisfying the `main()` requirement are the same as for satisfying a hypothetical protocol with a single requirement:
+
+```swift
+protocol ProvidesMain {
+ static func main() throws
+}
+```
+
+The `main()` method can be provided by the type itself, inherited from a superclass, or declared in an extension to a protocol the type conforms to. The `main()` method can either be declared as `throws` or not; errors thrown from a `main()` method will have the same behavior as errors thrown from top-level code.
+
+## Other considerations
+
+### Source compatibility
+
+This is a purely additive change and has no source compatibility impacts.
+
+### Effect on ABI stability and API resilience
+
+The new attribute is only applicable to application code, so there is no effect on ABI stability or API resilience.
+
+### Effect on SwiftPM packages
+
+The `@main` attribute will currently not be usable by Swift packages, since SwiftPM recognizes executable targets by looking for a `main.swift` file.
+
+## Alternatives
+
+### Use a special protocol instead of an attribute
+
+The standard library includes several protocols that the compiler imbues with special functionality, such as expressing instances of a type using literals and enabling `for`-`in` iteration for sequences. It would similarly be possible to define a `protocol Main` instead of creating a `@main` attribute, with the same requirements and special treatment. However, such a protocol wouldn’t enable any useful generalizations or algorithms, and the uniqueness requirement is totally non-standard for protocol conformance. These factors, plus the precedent of `@UIApplicationMain` and `@NSApplicationMain`, make the attribute a more appropriate way to designate a type as an entry point.
+
+### Allow `@main` to be applied to protocols
+
+One or more protocols could be attributed with `@main` to make any type that conforms an automatic entry point, with the compiler ensuring that only one such type exists in an application. As noted above, however, this uniqueness requirement is non-standard for protocols. In addition, this would make the entry point less explicit from the perspective of the program's author and maintainers, since the entry-point conforming type would look the same as any other. Likewise, this would prevent using _manual_ execution if a programmer still wanted to have custom logic in a `main.swift` file.
+
+### Use a `@propertyWrapper`-style type instead of an attribute
+
+Instead of a dedicated `@main` attribute, the compiler could let libraries declare a type that could act as an attribute used to denote a program's entry point. This approach is largely isomorphic to the proposed `@main` attribute, but loses the consistency of having a single way to spell the entry point, no matter which library you're using.
+
+### Use an instance instead of static method
+
+Instead of requiring a static `main()` method, the compiler could instead require `main()` as an instance method and a default initializer. This, however, would increase the implicit requirements of the `@main` attribute and split the entry point into two separate calls.
+
+In addition, a default initializer may not make sense for every type. For example, a web framework could offer a `main()` method that loads a configuration file and instantiates the type designated with `@main` using data from that configuration.
+
+### Use a different name for `main()`
+
+Some types may already define a static `main()` method with a different purpose than being a program’s entry point. A different, more specific name could avoid some of these potential collisions.
+
+However, adding `@main` isn’t source- or ABI-breaking for those types, as authors would already need to update their code with the new attribute and recompile to see any changed behavior. In addition, the `main` name matches the existing behavior of `main.swift`, as well as the name of the entry point in several other languages—C, Java, Rust, Kotlin, etc. all use functions or static methods named `main` as entry points.
+
+### Use `(Int, [String]) -> Int` or another signature for `main()`
+
+C programs define a function with the signature `int main(int argc, char *argv[])` as their entry point, with access to any arguments and returning a code indicating the status of the program. Swift programs have access to arguments through the `CommandLine` type, and can use `exit` to provide a status code, so the more complicated signature isn't strictly necessary.
+
+To eliminate any overhead in accessing arguments via `CommandLine` and to provide a way to handle platform-specific entry points, a future proposal could expand the ways that types can satisfy the `@main` requirement. For example, a type could supply either `main()` or `main(Int, [String]) -> Int`.
+
+Some platforms, such as Windows, base an executable's launch behavior on the specific entry point that the executable provides. A future direction could be to allow `@main` designated types to supply other specific entry points, such as `wWindowsMain(Int, UnsafeMutablePointer>) -> Int`, and to allow additional arguments to be given with the `@main` attribute:
+
+```swift
+// In a framework:
+extension ApplicationRoot {
+ static func main(console: Bool = true, ...) { ... }
+}
+
+@main(console: false)
+struct MyApp: Application {
+ // ...
+}
+```
+
+Alternatively, a future proposal could add an attribute that would let a library designate a different symbol name for the entry point:
+
+```swift
+// In a framework:
+extension ApplicationRoot {
+ @entryPoint(symbolName: "wWinMain", convention: stdcall)
+ static func main(_ hInstance: HINSTANCE, _ hPrevInstance: HINSTANCE, lpCmdLine: LPWSTR, _ nCmdShow: Int32) { ... }
+}
+```
+
+### Return `Never` instead of `Void`
+
+A previous design of this feature required the static `main()` method to return `Never` instead of `Void`, since that more precisely matches the semantics of how the method is used when invoked by the compiler. That said, because you can’t provide any top-level code when specifying the `@main` attribute, the `Void`-returning version of the method effectively acts like a `() -> Never` function.
+
+In addition, returning `Void` allows for more flexibility when the `main()` method is called manually. For example, an author might want to leave out the `@main` attribute and use top-level code to perform configuration, diagnostics, or other behavior before or after calling the static `main()` method.
diff --git a/proposals/0282-atomics.md b/proposals/0282-atomics.md
new file mode 100644
index 0000000000..21419fbb3c
--- /dev/null
+++ b/proposals/0282-atomics.md
@@ -0,0 +1,314 @@
+# Clarify the Swift memory consistency model ⚛︎
+
+* Proposal: [SE-0282](0282-atomics.md)
+* Author: [Karoy Lorentey](https://github.com/lorentey)
+* Review Manager: [Joe Groff](https://github.com/jckarter)
+* Bug: [SR-9144](https://bugs.swift.org/browse/SR-9144)
+* Implementation: Proof of concept [swift-atomics package][package]
+* Previous Revision: [v1][SE-0282v1] ([Returned for revision](https://forums.swift.org/t/se-0282-low-level-atomic-operations/35382/69))
+* Status: **Implemented (Swift 5.3)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0282-interoperability-with-the-c-atomic-operations-library/38050)
+
+[SE-0282v1]: https://github.com/swiftlang/swift-evolution/blob/3a358a07e878a58bec256639d2beb48461fc3177/proposals/0282-atomics.md
+[package]: https://github.com/apple/swift-atomics
+
+## Introduction
+
+This proposal adopts a C/C++-style weak concurrency memory model in Swift, describing how Swift code interoperates with concurrency primitives imported from C.
+
+This enables intrepid library authors to start building concurrency constructs in (mostly) pure Swift.
+
+Original swift-evolution thread: [Low-Level Atomic Operations](https://forums.swift.org/t/low-level-atomic-operations/34683)
+
+## Revision History
+
+- 2020-04-13: Initial proposal version.
+- 2020-06-05: First revision.
+ - Removed all new APIs; the proposal is now focused solely on C interoperability.
+
+## Table of Contents
+
+ * [Motivation](#motivation)
+ * [Proposed Solution](#proposed-solution)
+ * [Amendment to The Law of Exclusivity](#amendment-to-the-law-of-exclusivity)
+ * [Considerations for Library Authors](#considerations-for-library-authors)
+ * [Interaction with Non\-Instantaneous Accesses](#interaction-with-non-instantaneous-accesses)
+ * [Interaction with Implicit Pointer Conversions](#interaction-with-implicit-pointer-conversions)
+ * [Source Compatibility](#source-compatibility)
+ * [Effect on ABI Stability](#effect-on-abi-stability)
+ * [Effect on API Resilience](#effect-on-api-resilience)
+ * [Alternatives Considered](#alternatives-considered)
+ * [References](#references)
+
+## Motivation
+
+In Swift today, application developers use dispatch queues and Foundation's NSLocking protocol to synchronize access to mutable state across concurrent threads of execution.
+
+However, for Swift to be successful as a systems programming language, it needs to also be possible to implement such synchronization constructs (and many more!) directly within Swift. To allow this, we need to start describing a concurrency memory model.
+
+Given how deeply Swift interoperates with C, it seems reasonable to assume that Swift's concurrency memory model is compatible with the one described in the C standard. In fact, given that a large amount of existing Swift code deeply depends on concurrency constructs imported from C (most prominently the Dispatch library, but also POSIX Threads, `stdatomic.h` and others), fully embracing interoperability is very likely to be the only practical choice. Therefore, this proposal does exactly that -- it describes how C's atomic operations and memory orderings interact with Swift code.
+
+Having a reasonably well-defined meaning for the low-level atomic constructs defined for the C (and C++) memory model is crucial for people who wish to implement synchronization constructs or concurrent data structures directly in Swift. (Note that this is a hazardous area that is full of pitfalls. We expect that the higher-level synchronization tools that can be built on top of these atomic primitives will provide a nicer abstraction layer.)
+
+Note that while this proposal doesn't include a high-level concurrency design for Swift, it also doesn't preclude the eventual addition of one. Indeed, we expect that embracing a compatible concurrency memory model will serve as an important step towards language-level concurrency, by making it easier for motivated people to explore the design space on a library level.
+
+## Proposed Solution
+
+We propose to adopt a C/C++-style concurrency memory model for Swift code:
+
+* Concurrent write/write or read/write access to the same location in memory generally remains undefined/illegal behavior, unless all such access is done through a special set of primitive *atomic operations*.
+
+* The same atomic operations can also apply *memory ordering* constraints that establish strict before/after relationships for accesses across multiple threads of execution. Such constraints can also be established by explicit *memory fences* that aren't tied to a particular atomic operation.
+
+This document does not define a formal concurrency memory model in Swift, although we believe the methodology and tooling introduced for the C and C++ memory model and other languages could be adapted to work for Swift, too [[C18], [C++17], [Boehm 2008], [Batty 2011], [Nienhuis 2016], [Mattarei 2018]]. This proposal also doesn't come with any native concurrency primitives; it merely describes how C's preexisting constructs (`atomic_load_explicit`, `atomic_thread_fence`, etc.) can be used to synchronize Swift code.
+
+When applied carefully, atomic operations and memory ordering constraints can be used to implement higher-level synchronization algorithms that guarantee well-defined behavior for arbitrary variable accesses across multiple threads, by strictly confining their effects into some sequential timeline.
+
+For now, we will be heavily relying on the Law of Exclusivity as defined in [[SE-0176]] and the [[Ownership Manifesto]], and we'll explain to what extent C's memory orderings apply to Swift's variable accesses. The intention is that Swift's memory model will be fully interoperable with its C/C++ counterparts.
+
+This proposal does not specify whether/how dependency chains arising from the C/C++ `memory_order_consume` memory ordering work in Swift. The consume ordering as specified in the C/C++ standards is not implemented in any C/C++ compiler, and we join the current version of the C++ standard in encouraging Swift programmers not to use it. We expect to tackle the problem of efficient traversal of concurrent data structures in future proposals. Meanwhile, Swift programmers can start building useful concurrency constructs using relaxed, acquire/release, and sequentially consistent memory orderings imported from C.
+
+
+### Amendment to The Law of Exclusivity
+
+While the declarations in C's `stdatomic.h` header don't directly import into Swift, it is still possible to access these constructs from Swift code by [wrapping them into plain structs and functions][package] that can be imported. This way, `_Atomic` values can end up being stored within a Swift variable.
+
+When Swift code is able to acquire a stable pointer to the storage location of such a variable (by e.g. manually allocating it), it ought to be possible to pass this pointer to C's atomic functions to perform atomic operations on its value. Because C's atomic operations (`atomic_load`, `atomic_store`, `atomic_compare_exchange`, etc.) are inherently safe to execute concurrently, we must make sure that the Law of Exclusivity won't disallow them.
+
+While [[SE-0176]] didn't introduce any active enforcement of the Law of Exclusivity for unsafe pointers, it still defined overlapping read/write access to their pointee as an exclusivity violation.
+
+To resolve this problem, we propose to introduce the concept of *atomic access*, and to amend the Law of Exclusivity as follows:
+
+> Two accesses to the same variable aren't allowed to overlap unless both accesses are reads **or both accesses are atomic**.
+
+We define *atomic access* as a call to one of the following functions in the C atomic operation library:
+
+```text
+ atomic_flag_test_and_set atomic_flag_test_and_set_explicit
+ atomic_flag_clear atomic_flag_clear_explicit
+ atomic_store atomic_store_explicit
+ atomic_load atomic_load_explicit
+ atomic_exchange atomic_exchange_explicit
+ atomic_compare_exchange_strong atomic_compare_exchange_strong_explicit
+ atomic_compare_exchange_weak atomic_compare_exchange_weak_explicit
+ atomic_fetch_add atomic_fetch_add_explicit
+ atomic_fetch_sub atomic_fetch_sub_explicit
+ atomic_fetch_or atomic_fetch_or_explicit
+ atomic_fetch_xor atomic_fetch_xor_explicit
+ atomic_fetch_and atomic_fetch_and_explicit
+```
+
+We consider two of these operations to *access the same variable* if they operate on the same memory location. (Future proposals may introduce additional ways to perform atomic access, including native support for atomic operations in the Swift Standard Library.)
+
+We view the amendment above as merely formalizing pre-existing practice, rather than introducing any actual new constraint.
+
+> **Note:** As such, this proposal does not need to come with an associated implementation -- there is no need to change how the Swift compiler implements the Swift memory model. For example, there is no need to relax any existing compile-time or runtime checks for exclusivity violations, because unsafe pointer operations aren't currently covered by such checks. Similarly, the existing llvm-based Thread Sanitizer tool [[Tsan1], [TSan2]] already assumes a C-compatible memory model when it is run on Swift code.
+
+Like C, we leave mixed atomic/non-atomic access to the same memory location as undefined behavior, even if these mixed accesses are guaranteed to never overlap. (This restriction does not apply to accesses during storage initialization and deinitialization; those are always nonatomic.)
+
+## Considerations for Library Authors
+
+While this proposal enables the use of C's atomics operations in Swift code, we don't generally recommend calling C atomics API directly. Rather, we suggest wrapping the low-level atomic invocations in more appropriate Swift abstractions. As an example of how this can be done, we've made available a [proof of concept package][package] implementing the APIs originally included in the first version of this proposal.
+
+In this section we highlight some preexisting aspects of Swift's memory model that need to be taken into account when designing or using a C-based atomics library.
+
+This section doesn't propose any changes to the language or the Standard Library.
+
+### Interaction with Non-Instantaneous Accesses
+
+As described in [[SE-0176]], Swift allows accesses that are non-instantaneous. For example, calling a `mutating` method on a variable counts as a single write access that is active for the entire duration of the method call:
+
+```swift
+var integers: [Int] = ...
+...
+integers.sort() // A single, long write access
+```
+
+The Law of Exclusivity disallows overlapping read/write and write/write accesses to the same variable, so while one thread is performing `sort()`, no other thread is allowed to access `integers` at all. Note that this is independent of `sort()`'s implementation; it is merely a consequence of the fact that it is declared `mutating`.
+
+> **Note:** One reason for this is that the compiler may decide to implement the mutating call by first copying the current value of `integers` into a temporary variable, running `sort` on that, and then copying the resulting value back to `integers`. If `integers` had a computed getter and setter, this is in fact the only reasonable way to implement the mutating call. If overlapping access wasn't disallowed, such implicit copying would lead to race conditions even if the `mutating` method did not actually mutate any data at all.
+
+While C's atomic memory orderings do apply to Swift's variable accesses, and we can use them to reliably synchronize Swift code, they can only apply to accesses whose duration doesn't overlap with the atomic operations themselves. They inherently cannot synchronize variable accesses that are still in progress while the atomic operation is being executed. Code that relies on memory orderings must be carefully written to take this into account.
+
+For example, it isn't possible to implement any "thread-safe" `mutating` methods, no matter how much synchronization we add to their implementation. The following attempt to implement an "atomic" increment operation on `Int` is inherently doomed to failure:
+
+```swift
+import Dispatch
+import Foundation
+
+let _mutex = NSLock()
+
+extension Int {
+ mutating func atomicIncrement() { // BROKEN, DO NOT USE
+ _mutex.lock()
+ self += 1
+ _mutex.unlock()
+ }
+}
+
+var i: Int
+...
+i = 0
+DispatchQueue.concurrentPerform(iterations: 10) { _ in
+ for _ in 0 ..< 1_000_000 {
+ i.atomicIncrement() // Exclusivity violation
+ }
+}
+print(i)
+```
+
+Even though `NSLock` does guarantee that the `self += 1` line is always serialized, any concurrent `atomicIncrement` invocations still count as an exclusivity violation, because the write access to `i` starts when the function call begins, before the call to `_mutex.lock()`. Therefore, the code above has undefined behavior, despite all the locking. (For example, it may print any value between one and ten million, or it may trap in a runtime exclusivity check, or indeed it may do something else.)
+
+The same argument also applies to property and subscript setters (unless they are declared `nonmutating`), and to `inout` arguments of any function call.
+
+Methods of types with reference semantics (such as classes) can modify their instance variables without declaring themselves `mutating`, so they aren't constrained by this limitation. (Of course, the implementation of the method must still guarantee that the Law is upheld for any stored properties they themselves access -- but synchronization tools such as locks do work in this context.)
+
+### Interaction with Implicit Pointer Conversions
+
+
+To simplify interoperability with functions imported from C, Swift provides several forms of implicit conversions from Swift values to unsafe pointers. This often requires the use of Swift's special `&` syntax for passing inout values. At first glance, this use of the ampersand resembles C's address-of operator, and it seems to work in a similar way:
+
+```swift
+func test(_ address: UnsafePointer)
+
+var value = 42
+
+// Implicit conversion from `inout Int` to `UnsafePointer`
+test(&value)
+```
+
+However, despite the superficial similarity, the `&` here isn't an address-of operator at all. Swift variables do not necessarily have a stable location in memory, and even in case they happen to get assigned one, there is generally no reliable way to retrieve the address of their storage. (The obvious exceptions are dynamic variables that we explicitly allocate ourselves.) What the `&`-to-pointer conversion actually does here is equivalent to a call to `withUnsafePointer(to:)`:
+
+```swift
+withUnsafePointer(to: &value) { pointer in
+ test(pointer)
+}
+```
+
+This counts as a write access to the original value, and (unlike with C) the generated pointer may address a temporary copy of the value -- so it is only considered valid for the duration of the closure call, and the addressed memory location may change every time the code is executed. Because of these two reasons, inout-to-pointer conversions must not be employed to pass "the address" of an atomic value to an atomic operation.
+
+For example, consider the following constructs, imported from C wrappers of `_Atomic intptr_t`, `atomic_load` and `atomic_fetch_add`:
+
+```swift
+struct AtomicIntStorage { ... }
+func atomicLoadInt(_ address: UnsafePointer) -> Int
+func atomicFetchAddInt(
+ _ address: UnsafeMutablePointer,
+ _ delta: Int
+) -> Int
+```
+
+It is tempting to call these by simply passing an inout reference to a Swift variable of type `AtomicIntStorage`:
+
+```swift
+// BROKEN, DO NOT USE
+var counter = AtomicIntStorage() // zero init
+DispatchQueue.concurrentPerform(iterations: 10) { _ in
+ for _ in 0 ..< 1_000_000 {
+ atomicFetchAddInt(&counter, 1) // Exclusivity violation
+ }
+}
+print(atomicLoadInt(&counter) // ???
+```
+
+Unfortunately, this code has undefined behavior. `&counter` counts as a write access to `counter`, and as we explained in the previous section, this leads to a clear exclusivity violation. Additionally, `&counter` may result in a different pointer in each thread of execution (or, perhaps even each iteration of the loop), which would defeat atomicity.
+
+Given that the concurrency in this example is neatly isolated to a single section of code, we could wrap it in a `withUnsafeMutablePointer(to:)` invocation that generates a single (but still temporary) pointer. This resolves the problem:
+
+```swift
+var counter = AtomicIntStorage() // zero init
+withUnsafeMutablePointer(to: counter) { pointer in
+ DispatchQueue.concurrentPerform(iterations: 10) { _ in
+ for _ in 0 ..< 1_000_000 {
+ atomicFetchAddInt(pointer, 1) // OK
+ }
+ }
+ print(atomicLoadInt(pointer) // 10_000_000
+}
+```
+
+However, it isn't always possible to do this. In cases where thread lifetime cannot be restricted to a single code block, the best way to produce a pointer that is suitable for atomic operations is either by manually allocating a dynamic variable, or by using `ManagedBuffer` APIs to retrieve stable pointers to inline storage inside a class instance.
+
+
+## Source Compatibility
+
+This proposal requires no changes to Swift's implementation; as such, it has no source compatibility impact.
+
+## Effect on ABI Stability
+
+None.
+
+## Effect on API Resilience
+
+None.
+
+## Alternatives Considered
+
+A previous version of this proposal included a large set of APIs implementing a native Swift atomics facility. We expect a revised version of these APIs will return in a followup proposal later (following further work on Swift's [Ownership Manifesto]); however, for now, we expect to develop them [as a standalone package][package], implemented around the operations provided by the C standard library. This C-based reimplementation of the module exports the same public interface and it has the same performance characteristics as the originally proposed native implementation.
+
+## References
+
+[Ownership Manifesto]: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md
+**\[Ownership Manifesto]** John McCall. "Ownership Manifesto." *Swift compiler documentation*, May 2, 2017. https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md
+
+[SE-0176]: https://github.com/swiftlang/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
+**\[SE-0176]** John McCall. "Enforce Exclusive Access to Memory. *Swift Evolution Proposal,* SE-0176, May 2, 2017. https://github.com/swiftlang/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
+
+[Generics Manifesto]: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
+**\[Generics Manifesto]** Douglas Gregor. "Generics Manifesto." *Swift compiler documentation*, 2016. https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
+
+[C++17]: https://isocpp.org/std/the-standard
+**\[C++17]** ISO/IEC. *ISO International Standard ISO/IEC 14882:2017(E) – Programming Language C++.* 2017.
+https://isocpp.org/std/the-standard
+
+[C18]: https://www.iso.org/standard/74528.html
+**\[C18]** *ISO International Standard ISO/IEC 9899:2018 - Information Technology -- Programming Languages -- C.*. 2018.
+https://www.iso.org/standard/74528.html
+
+**\[Williams 2019]** Anthony Williams. *C++ Concurrency in Action.* 2nd ed., Manning, 2019.
+
+**\[Nagarajan 2020]** Vijay Nagarajan, Daniel J. Sorin, Mark D. Hill, David A. Wood. *A Primer on Memory Consistency and Cache Coherence.* 2nd ed., Morgan & Claypool, February 2020. https://doi.org/10.2200/S00962ED2V01Y201910CAC049
+
+**\[Herlihy 2012]** Maurice Herlihy, Nir Shavit. *The Art of Multiprocessor Programming.* Revised 1st ed., Morgan Kauffmann, May 2012.
+
+[Boehm 2008]: https://doi.org/10.1145/1375581.1375591
+**\[Boehm 2008]** Hans-J. Boehm, Sarita V. Adve. "Foundations of the C++ Concurrency Memory Model." In *PLDI '08: Proc. of the 29th ACM SIGPLAN Conf. on Programming Language Design and Implementation*, pages 68–78, June 2008.
+ https://doi.org/10.1145/1375581.1375591
+
+[Batty 2011]: https://doi.org/10.1145/1925844.1926394
+**\[Batty 2011]** Mark Batty, Scott Owens, Susmit Sarkar, Peter Sewell, Tjark Weber. "Mathematizing C++ Concurrency." In *ACM SIGPlan Not.,* volume 46, issue 1, pages 55–66, January 2011. https://doi.org/10.1145/1925844.1926394
+
+[Boehm 2012]: https://doi.org/10.1145/2247684.2247688
+**\[Boehm 2012]** Hans-J. Boehm. "Can Seqlocks Get Along With Programming Language Memory Models?" In *MSPC '12: Proc. of the 2012 ACM SIGPLAN Workshop on Memory Systems Performance and Correctness*, pages 12–20, June 2012. https://doi.org/10.1145/2247684.2247688
+
+[Nienhuis 2016]: https://doi.org/10.1145/2983990.2983997
+**\[Nienhuis 2016]** Kyndylan Nienhuis, Kayvan Memarian, Peter Sewell. "An Operational Semantics for C/C++11 Concurrency." In *OOPSLA 2016: Proc. of the 2016 ACM SIGPLAN Conf. on Object Oriented Programming, Systems, Languages, and Applications,* pages 111–128, October 2016. https://doi.org/10.1145/2983990.2983997
+
+[Mattarei 2018]: https://doi.org/10.1007/978-3-319-89963-3_4
+**\[Mattarei 2018]** Christian Mattarei, Clark Barrett, Shu-yu Guo, Bradley Nelson, Ben Smith. "EMME: a formal tool for ECMAScript Memory Model Evaluation." In *TACAS 2018: Lecture Notes in Computer Science*, vol 10806, pages 55–71, Springer, 2018. https://doi.org/10.1007/978-3-319-89963-3_4
+
+[N2153]: http://wg21.link/N2153
+**\[N2153]** Raúl Silvera, Michael Wong, Paul McKenney, Bob Blainey. *A simple and efficient memory model for weakly-ordered architectures.* WG21/N2153, January 12, 2007. http://wg21.link/N2153
+
+[N4455]: http://wg21.link/N4455
+**\[N4455]** JF Bastien *No Sane Compiler Would Optimize Atomics.* WG21/N4455, April 10, 2015. http://wg21.link/N4455
+
+[P0124]: http://wg21.link/P0124
+**\[P0124]** Paul E. McKenney, Ulrich Weigand, Andrea Parri, Boqun Feng. *Linux-Kernel Memory Model.* WG21/P0124r6. September 27, 2018. http://wg21.link/P0124
+
+[TSan1]: https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer
+**\[TSan1]** *Thread Sanitizer -- Audit threading issues in your code.* Apple Developer Documentation. Retrieved March 2020. https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer
+
+[TSan2]: https://clang.llvm.org/docs/ThreadSanitizer.html
+**\[TSan2]** *ThreadSanitizer*. Clang 11 documentation. Retrieved March 2020. https://clang.llvm.org/docs/ThreadSanitizer.html
+
+
+⚛︎︎
+
+
+
+
+
+
+
+
diff --git a/proposals/0283-tuples-are-equatable-comparable-hashable.md b/proposals/0283-tuples-are-equatable-comparable-hashable.md
new file mode 100644
index 0000000000..963cf56eaf
--- /dev/null
+++ b/proposals/0283-tuples-are-equatable-comparable-hashable.md
@@ -0,0 +1,156 @@
+# Tuples Conform to `Equatable`, `Comparable`, and `Hashable`
+
+* Proposal: [SE-0283](0283-tuples-are-equatable-comparable-hashable.md)
+* Author: [Alejandro Alonso](https://github.com/Azoy)
+* Review Manager: [Saleem Abdulrasool](https://github.com/compnerd)
+* Status: **Accepted (2020-05-19)**
+* Implementation: [apple/swift#28833](https://github.com/apple/swift/pull/28833)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0283-tuples-conform-to-equatable-comparable-and-hashable/36658), [Additional Commentary](https://forums.swift.org/t/implementation-issues-with-se-0283-tuples-are-ehc/46946)
+
+## Introduction
+
+Introduce `Equatable`, `Comparable`, and `Hashable` conformance for all tuples whose elements are themselves `Equatable`, `Comparable`, and `Hashable`.
+
+Swift-evolution thread: [Tuples Conform to Equatable, Comparable, and Hashable](https://forums.swift.org/t/tuples-conform-to-equatable-comparable-and-hashable/34156)
+
+## Motivation
+
+Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that can conform to protocols. The shift — from tuples to structures — has made tuples almost feel like a second-class type in the language, because of them not being able to do simple operations that should *just* work.
+
+Consider the following snippet of code that naively tries to use tuples for simple operations, but instead is faced with ugly errors.
+
+```swift
+let points = [(x: 128, y: 316), (x: 0, y: 0), (x: 100, y: 42)]
+let origin = (x: 0, y: 0)
+
+// error: type '(x: Int, y: Int)' cannot conform to 'Equatable';
+// only struct/enum/class types can conform to protocols
+if points.contains(origin) {
+ // do some serious calculations here
+}
+
+// error: type '(x: Int, y: Int)' cannot conform to 'Comparable';
+// only struct/enum/class types can conform to protocols
+let sortedPoints = points.sorted()
+
+// error: type '(x: Int, y: Int)' cannot conform to 'Hashable';
+// only struct/enum/class types can conform to protocols
+let uniquePoints = Set(points)
+```
+
+This also creates friction when one needs to conditionally conform to a type, or if a type is just trying to get free conformance synthesis for protocols like `Equatable` or `Hashable`.
+
+```swift
+struct Restaurant {
+ let name: String
+ let location: (latitude: Int, longitude: Int)
+}
+
+// error: type 'Restaurant' does not conform to protocol 'Equatable'
+extension Restaurant: Equatable {}
+
+// error: type 'Restaurant' does not conform to protocol 'Hashable'
+extension Restaurant: Hashable {}
+```
+
+These are simple and innocent examples of trying to use tuples in one's code, but currently the language lacks the means to get these examples working and prevents the user from writing this code.
+
+After all the errors, one decides to give in and create a structure to mimic the tuple layout. From a code size perspective, creating structures to mimic each unique tuple need adds a somewhat significant amount of size to one's binary.
+
+## Proposed solution
+
+Introduce `Equatable`, `Comparable`, and `Hashable` conformance for all tuples whose elements themselves conform to said protocols. While this isn't a general-purpose "conform any tuple to any protocol" proposal, `Equatable`, `Comparable`, and `Hashable` are crucial protocols to conform to, because it allows for all of the snippets above in Motivation to compile and run as expected, along with many other standard library operations to work nicely with tuples.
+
+### Equatable
+
+The rule is simple: if all of the tuple elements are themselves `Equatable` then the overall tuple itself conforms to `Equatable`.
+
+```swift
+// Ok, Int is Equatable thus the tuples are Equatable
+(1, 2, 3) == (1, 2, 3) // true
+
+struct EmptyStruct {}
+
+// error: type '(EmptyStruct, Int, Int)' does not conform to protocol 'Equatable'
+// note: value of type 'EmptyStruct' does not conform to protocol 'Equatable',
+// preventing conformance of '(EmptyStruct, Int, Int)' to 'Equatable'
+(EmptyStruct(), 1, 2) == (EmptyStruct(), 1, 2)
+```
+
+It's also important to note that this conformance does not take into account the tuple labels in consideration for equality. If both tuples have the same element types, then they can be compared for equality. This mimics the current behavior of the operations introduced in [SE-0015](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md).
+
+```swift
+// We don't take into account the labels for equality.
+(x: 0, y: 0) == (0, 0) // true
+```
+
+### Comparable
+
+Comparable conformance for tuples works just like `Equatable`, if all the elements themselves are `Comparable`, then the tuple itself is `Comparable`. Comparing a tuple to a tuple works elementwise:
+
+> Look at the first element, if they are equal move to the second element.
+Repeat until we find elements that are not equal and compare them.
+
+If all of the elements are equal, we cannot compare them, thus the result is `false`. Of course if we're using `<=` or `>=` and the tuples are exactly the same then the output would be `true`.
+
+```swift
+let origin = (x: 0, y: 0)
+let randomPoint = (x: Int.random(in: 1 ... 10), y: Int.random(in: 1 ... 10))
+
+// In this case, the first element of origin is 0 and the first element
+// of randomPoint is somewhere between 1 and 10, so they are not equal.
+// origin's element is less than randomPoint's, thus true.
+print(origin < randomPoint) // true
+```
+
+Just like in `Equatable`, the comparison operations do not take tuple labels into consideration when determining comparability. This mimics the current behavior of the operations introduced in [SE-0015](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md).
+
+```swift
+// We don't take into account the labels for comparison.
+(x: 0, y: 0) < (1, 0) // true
+```
+
+### Hashable
+
+The same rule applies to `Hashable` as it does for `Comparable` and `Equatable`, if all the elements are `Hashable` then the tuple itself is `Hashable`. When hashing a value of a tuple, all of the elements are combined into the hasher to produce the tuple's hash value. Now that tuples are `Hashable`, one can make a set of tuples or create dictionaries with tuple keys:
+
+```swift
+let points = [(x: 0, y: 0), (x: 1, y: 2), (x: 0, y: 0)]
+let uniquePoints = Set(points)
+
+// Create a grid system to hold game entities.
+var grid = [(x: Int, y: Int): Entity]()
+
+for point in uniquePoints {
+ grid[point]?.move(up: 10)
+}
+```
+
+Once again, `Hashable` doesn't take tuple element labels into consideration when evaluating the hash value of a tuple. Because of this, one is able to index into a set or dictionary with an unlabeled tuple and retrieve elements whose keys were labeled tuples:
+
+```swift
+// We don't take into account the labels for hash value.
+(x: 0, y: 0).hashValue == (0, 0).hashValue // true
+
+grid[(x: 100, y: 200)] = Entity(name: "Pam")
+
+print(grid[(100, 200)]) // Entity(name: "Pam")
+```
+
+## Source compatibility
+
+These are completely new conformances to tuples, thus source compatibility is unaffected as they were previously not able to conform to protocols.
+
+## Effect on ABI stability
+
+The conformances to `Equatable`, `Comparable`, and `Hashable` are all additive to the ABI. While at the time of writing this, there is no way to spell a new conformance to an existing type. However, these conformances are being implemented within the runtime which allows us to backward deploy these conformance to Swift 5.0, 5.1, and 5.2 clients. Because these are special conformances being added before other language features allows us to create real conformances, there is a level of runtime support needed to enable these conformances to work properly. Going forward this means we'll need to keep the entry points needed for these to work even after tuples are able to properly conform to protocols.
+
+## Alternatives considered
+
+Besides not doing this entirely, the only alternative here is whether or not we should hold off on this before we get proper protocol conformances for tuples which allow them to conform to any protocol. Doing this now requires a lot of builtin machinery in the compiler which some may refer to as technical debt. While I agree with this statement, I don't believe we should be holding off on features like this that many are naturally reaching for until bigger and more complex proposals that allow this feature to natively exist in Swift. I also believe it is none of the user's concern for what technical debt is added to the compiler that allows them to write the Swift code that they feel comfortable writing. In any case, the technical debt to be had here should only be the changes to the runtime (or at least the symbols needed) which allow this feature to work.
+
+## Future Directions
+
+With this change, other conformances such as `Codable` might make sense for tuples as well. It also makes sense to implement other conformances for other structural types in the language such as metatypes being `Hashable`, existentials being `Equatable` and `Hashable`, etc.
+
+In the future when we have proper tuple extensions along with variadic generics and such, implementing these conformances for tuples will be trivial and I imagine the standard library will come with these conformances for tuples. When that happens all future usage of those conformances will use the standard library's implementation, but older clients that have been compiled with this implementation will continue using it as normal.
diff --git a/proposals/0284-multiple-variadic-parameters.md b/proposals/0284-multiple-variadic-parameters.md
new file mode 100644
index 0000000000..3ec42bab99
--- /dev/null
+++ b/proposals/0284-multiple-variadic-parameters.md
@@ -0,0 +1,164 @@
+# Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers
+
+* Proposal: [SE-0284](0284-multiple-variadic-parameters.md)
+* Author: [Owen Voorhees](https://github.com/owenv)
+* Review Manager: [Saleem Abdulrasool](https://github.com/compnerd)
+* Status: **Implemented (Swift 5.4)**
+* Implementation: [apple/swift#29735](https://github.com/apple/swift/pull/29735)
+
+## Introduction
+
+Currently, variadic parameters in Swift are subject to two main restrictions:
+
+- Only one variadic parameter is allowed per parameter list
+- If present, the parameter which follows a variadic parameter must be labeled
+
+This proposal seeks to remove the first restriction while leaving the second in place, allowing a function, subscript, or initializer to have multiple variadic parameters so long as every parameter which follows a variadic one has a label.
+
+Swift-evolution thread: [Lifting the 1 variadic param per function restriction](https://forums.swift.org/t/lifting-the-1-variadic-param-per-function-restriction/33787?u=owenv)
+
+## Motivation
+
+Variadic parameters allow programmers to write clear, succinct APIs which operate on a variable, but compile-time fixed number of inputs. One prominent example is the standard library's `print` function. However, restricting each function to a single variadic parameter can sometimes be limiting. For example, consider the following example from the `swift-driver` project:
+
+```swift
+func assertArgs(
+ _ args: String...,
+ parseTo driverKind: DriverKind,
+ leaving remainingArgs: ArraySlice,
+ file: StaticString = #file, line: UInt = #line
+ ) throws { /* Implementation Omitted */ }
+
+try assertArgs("swift", "-foo", "-bar", parseTo: .interactive, leaving: ["-foo", "-bar"])
+```
+
+Currently, the `leaving:` parameter cannot be variadic because of the preceding unnamed variadic parameter. This results in an odd inconsistency, where the first list of arguments does not require brackets, but the second does. By allowing multiple variadic parameters, it could be rewritten like so:
+
+```swift
+func assertArgs(
+ _ args: String...,
+ parseTo driverKind: DriverKind,
+ leaving remainingArgs: String...,
+ file: StaticString = #file, line: UInt = #line
+ ) throws { /* Implementation Omitted */ }
+
+try assertArgs("swift", "-foo", "-bar", parseTo: .interactive, leaving: "-foo", "-bar")
+```
+
+This results in a cleaner, more consistent interface.
+
+Multiple variadic parameters can also be used to streamline lightweight DSL-like functions. For example, one could write a simple autolayout wrapper like the following:
+
+```swift
+extension UIView {
+ func addSubviews(_ views: UIView..., constraints: NSLayoutConstraint...) {
+ views.forEach {
+ addSubview($0)
+ $0.translatesAutoresizingMaskIntoConstraints = false
+ }
+ constraints.forEach { $0.isActive = true }
+ }
+}
+
+myView.addSubviews(v1, v2, constraints: v1.widthAnchor.constraint(equalTo: v2.widthAnchor),
+ v1.heightAnchor.constraint(equalToConstant: 40),
+ /* More Constraints... */)
+```
+
+## Proposed solution
+
+Lift the arbitrary restriction on variadic parameter count and allow a function/subscript/initializer to have any number of them. Leave in place the restriction which requires any parameter following a variadic one to have a label.
+
+## Detailed design
+
+A variadic parameter can already appear anywhere in a parameter list, so the behavior of multiple variadic parameters in functions and initializers is fully specified by the existing language rules.
+
+```swift
+// Note the label on the second parameter is required because it follows a variadic parameter.
+func twoVarargs(_ a: Int..., b: Int...) { }
+twoVarargs(1, 2, 3, b: 4, 5, 6)
+
+// Variadic parameters can be omitted because they default to [].
+twoVarargs(1, 2, 3)
+twoVarargs(b: 4, 5, 6)
+twoVarargs()
+
+// The third parameter does not require a label because the second isn't variadic.
+func splitVarargs(a: Int..., b: Int, _ c: Int...) { }
+splitVarargs(a: 1, 2, 3, b: 4, 5, 6, 7)
+// a is [1, 2, 3], b is 4, c is [5, 6, 7].
+splitVarargs(b: 4)
+// a is [], b is 4, c is [].
+
+// Note the third parameter doesn't need a label even though the second has a default expression. This
+// is consistent with the current behavior, which allows a variadic parameter followed by a labeled,
+// defaulted parameter, followed by an unlabeled required parameter.
+func varargsSplitByDefaultedParam(_ a: Int..., b: Int = 42, _ c: Int...) { }
+varargsSplitByDefaultedParam(1, 2, 3, b: 4, 5, 6, 7)
+// a is [1, 2, 3], b is 4, c is [5, 6, 7].
+varargsSplitByDefaultedParam(b: 4, 5, 6, 7)
+// a is [], b is 4, c is [5, 6, 7].
+varargsSplitByDefaultedParam(1, 2, 3)
+// a is [1, 2, 3], b is 42, c is [].
+// Note: it is impossible to call varargsSplitByDefaultedParam providing a value for the third parameter
+// without also providing a value for the second.
+```
+
+This proposal also allows subscripts to have more than one variadic parameter. Like in functions and initializers, a subscript parameter which follows a variadic parameter must have an external label. However, the syntax differs slightly because of the existing labeling rules for subscript parameters:
+
+```swift
+struct HasSubscript {
+ // Not allowed because the second parameter does not have an external label.
+ subscript(a: Int..., b: Int...) -> [Int] { a + b }
+
+ // Allowed
+ subscript(a: Int..., b b: Int...) -> [Int] { a + b }
+}
+```
+
+Note that due to a long-standing bug, the following subscript declarations are accepted by the current compiler:
+
+```swift
+struct HasBadSubscripts {
+ // Shouldn't be allowed because the second parameter follows a variadic one and has no
+ // label. Is accepted by the current compiler but can't be called.
+ subscript(a: Int..., b: String) -> Int { 0 }
+
+ // Shouldn't be allowed because the second parameter follows a variadic one and has no
+ // label. Is accepted by the current compiler and can be called, but the second
+ // parameter cannot be manually specified.
+ subscript(a: Int..., b: String = "hello, world!") -> Bool { false }
+}
+```
+
+This proposal makes both declarations a compile time error. This is a source compatibility break, but a very small one which only affects declarations with no practical use. This bug also affects closure parameter lists:
+
+```swift
+// Currently allowed, but impossible to call.
+let closure = {(a: Int..., b: Int) in}
+```
+
+Under this proposal, the above code also becomes a compile-time error. Note that because closures do not allow external parameter labels, they cannot support multiple variadic parameters.
+
+## Source compatibility
+
+As noted above, this proposal is source-breaking for any program which has a subscript declaration or closure having an unlabeled parameter following a variadic parameter. With the exception of very specific subscript declarations making use of default parameters, this only affects parameter lists which are syntactically impossible to fulfill. As a result, the break should have no impact on the vast majority of existing codebases. It does not cause any failures in the source compatibility suite.
+
+If this source-breaking change is considered unacceptable, there are two alternatives. One would be to change the error to a warning when applied to subscripts and closures. The other would be to preserve the buggy behavior and emit no diagnostics. In both cases, multiple variadic parameters would continue to be supported by subscripts, but users would retain the ability to write parameter lists which can't be fulfilled in some contexts.
+
+## Effect on ABI stability
+
+This proposal does not require any changes to the ABI. The current ABI representation of variadic parameters already supports more than one per function/subscript/initializer.
+
+## Effect on API resilience
+
+An ABI-public function may not add, remove, or reorder parameters, whether or not they have default arguments or are variadic. This rule is unchanged and applies to all variadic parameters.
+
+## Alternatives considered
+
+Two alternative labeling rules were considered.
+
+1. If a parameter list has more than one variadic parameter, every variadic parameter must have a label.
+2. If a parameter list has more than one variadic parameter, every variadic parameter except for the first must have a label.
+
+Both alternatives are more restrictive in terms of the declarations they allow. This increases complexity and makes the parameter labeling rules harder to reason about. However, they might make it more difficult to write confusing APIs which mix variadic, defaulted, and required parameters. Overall, it seems better to trust programmers with greater flexibility, while also minimizing the number of rules they need to learn.
diff --git a/proposals/0285-ease-pound-file-transition.md b/proposals/0285-ease-pound-file-transition.md
new file mode 100644
index 0000000000..fd73519258
--- /dev/null
+++ b/proposals/0285-ease-pound-file-transition.md
@@ -0,0 +1,175 @@
+# Ease the transition to concise magic file strings
+
+* Proposal: [SE-0285](0285-ease-pound-file-transition.md)
+* Author: [Becca Royal-Gordon](https://github.com/beccadax)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Implementation: [apple/swift#32700](https://github.com/apple/swift/pull/32700)
+* Status: **Implemented (Swift 5.3)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0285-ease-the-transition-to-concise-magic-file-strings/38516)
+
+## Introduction
+
+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.
+
+Swift-evolution thread: [Revisiting the source compatibility impact of SE-0274: Concise magic file names](https://forums.swift.org/t/revisiting-the-source-compatibility-impact-of-se-0274-concise-magic-file-names/37720/)
+
+ [SE-0274]: https://github.com/swiftlang/swift-evolution/blob/master/proposals/0274-magic-file.md
+
+## Motivation
+
+SE-0274 made the following changes:
+
+1. Introduced a new `#filePath` magic identifier which, like `#file` in prior versions of Swift, evaluates to the source file path passed when the compiler was invoked.
+
+2. Modified the `#file` magic identifier to instead evaluate to a string of the form `ModuleName/FileName.swift`. (See SE-0274 for discussions of the motivations for this.)
+
+3. Added a warning when, essentially, a wrapper around a function with a `#filePath` default argument inadvertently captured `#file` instead, or vice versa.
+
+After acceptance, changes 1 and 3 were enabled in the release/5.3 branch. Change 2 was gated by a staging flag and was expected to be enabled in the release after 5.3.
+
+On paper, this seemed like a workable plan, giving developers the entire Swift 5.3 cycle to update code like this:
+
+```swift
+/// Prints the path to the file it was called from.
+func printSourcePath(file: String = #file) { print(file) }
+```
+
+To this when necessary:
+
+```swift
+/// Prints the path to the file it was called from.
+func printSourcePath(file: String = #filePath) { print(file) }
+```
+
+However, many source-distributed libraries like SwiftNIO need more than one version of backwards compatibility in use sites which will need to transition to `#filePath`. Their authors had believed they could achieve this using `#if compiler(>=5.3)` directives, but when they began to implement these workarounds, they found they were stymied by language limitations.
+
+For instance, they believed they would be able to use a helper function to abstract the choice of `#file` or `#filePath`, not realizing that the magic call-site behavior of `#file` and `#filePath` in default arguments isn't transitive:
+
+```swift
+/// Prints the path to the file it was called from.
+/// - Warning: Actually prints the path to the file `printSourcePath(file:)` was
+/// defined in instead!
+func printSourcePath(file: String = filePathOrFile()) { print(file) }
+
+#if compiler(>=5.3)
+ func filePathOrFile(_ value: String = #filePath) -> String { value }
+#else
+ func filePathOrFile(_ value: String = #file) -> String { value }
+#endif
+```
+
+They also believed they could use `#if` in default arguments, not realizing that `#if` directives can only be wrapped around whole statements or declarations:
+
+```swift
+/// Prints the path to the file it was called from.
+/// - Warning: Actually fails to compile with a syntax error!
+func printSourcePath(file: String = #if compiler(>=5.3)
+ #filePath
+ #else
+ #file
+ #endif) { print(file) }
+```
+
+That left them with with only one reasonable option—conditionally-selected wrapper functions—which they understandably considered too burdensome:
+
+```swift
+fileprivate func _printSourcePathImpl(file: String) { print(file) }
+
+#if compiler(>=5.3)
+/// Prints the path to the file it was called from.
+func printSourcePath(file: String = #filePath) { _printSourcePathImpl(file: file) }
+#else
+/// Prints the path to the file it was called from.
+func printSourcePath(file: String = #file) { _printSourcePathImpl(file: file) }
+#endif
+```
+
+While we still want to reach the same endpoint—most code using a syntax with concise file strings while full paths are still available to the use sites that need them—it has become clear that this transition needs to be more gradual, with `#file` continuing to have its current meaning in Swift 5 projects indefinitely.
+
+## Proposed solution
+
+We propose to modify all three aspects of SE-0274's changes:
+
+1. In addition to `#filePath`, we will introduce a new `#fileID` magic identifier, which generates the new concise file string in all language modes.
+
+2. `#file` will continue to produce the same string as `#filePath` in the Swift 5 and earlier language modes. When code is compiled using future language modes (e.g. a hypothetical "Swift 6 mode"[1]), `#file` will generate the same string as `#fileID`, and `#fileID` will be deprecated.
+
+3. In Swift 5 mode, for the purposes of the "wrong magic identifier literal" warning, `#file` will be treated as compatible with *both* `#filePath` and `#fileID`. In future language modes, it will be treated as compatible with only `#fileID`.
+
+
+
+[1]
+
+> "Swift 6" is purely illustrative. There is no guarantee that Swift 6 will be a source-breaking version, that there won't be a source-breaking version before Swift 6, or indeed that there will ever be a Swift 6 at all. Offer void where prohibited.
+
+
+
+## Detailed design
+
+### The `#fileID` magic identifier literal
+
+In addition to the existing `#file` and the new `#filePath`, Swift will support `#fileID`. This new magic identifier will generate the same module-and-filename string SE-0274 specified for `#file`. It will do so immediately, without any way to reverse its behavior.
+
+Standard library assertion functions like `assert`, `precondition`, and `fatalError` will switch from `#file` to `#fileID`. When a filename is included in a compiler-generated trap, such as a force unwrap, it will also emit a literal equivalent to using `#fileID`.
+
+`#fileID` is intended to allow Swift 5.3 code to adopt the new, more compact literals before the behavior of `#file` changes. In language version modes where `#file` produces the same string as `#fileID`, `#fileID` will be deprecated.
+
+### Transitioning the `#file` magic identifier
+
+The `#file` identifier will continue to generate the same string as `#filePath` in Swift 4, 4.2, and 5 modes. In any future language version modes, it will instead generate the `#fileID` string. This means that the change in `#file`'s behavior—and therefore the requirement to change some uses of `#file` to `#filePath`—will be delayed until Swift next makes source-breaking changes, and even then, the current behavior will be preserved in Swift 5 mode.
+
+If a client compiled in Swift 5 mode or earlier uses a library compiled with a later language mode, the library's `#file` default arguments will be treated as though they were `#fileID`; if a client compiled with a later language mode uses a library compiled in Swift 5 mode or earlier, the library's `#file` default arguments will be treated as though they were `#filePath`.
+
+### Magic identifier default argument mismatch warnings
+
+Swift will not warn when:
+
+* A parameter with a default argument of `#file` is passed to one with a default argument of `#fileID`.
+* A parameter with a default argument of `#fileID` is passed to one with a default argument of `#file`.
+
+Additionally, Swift 5 mode and earlier will not warn when:
+
+* A parameter with a default argument of `#file` is passed to one with a default argument of `#filePath`.
+* A parameter with a default argument of `#filePath` is passed to one with a default argument of `#file`.
+
+In Swift 5 mode, substituting `#file` for `#fileID` *will* actually result in different behavior, so ideally we would warn about this. However, doing that would cause new warnings in existing functions which wrap functions that adopt `#fileID`. In practice, most `#fileID` adopters will work fine when they're passed `#file`—they'll just generate unnecessarily large file strings.
+
+### Swift API Design Guidelines amendment
+
+This guideline will be added to [the "Parameters" section][api-params] of the Swift API Design Guidelines:
+
+> * **If your API will run in production, prefer `#fileID`** over alternatives.
+> `#fileID` saves space and protects developers’ privacy. Use `#filePath` in
+> APIs that are never run by end users (such as test helpers and scripts) if
+> the full path will simplify development workflows or be used for file I/O.
+> Use `#file` to preserve source compatibility with Swift 5.2 or earlier.
+
+ [api-params]: https://swift.org/documentation/api-design-guidelines/#parameter-names
+
+### Schedule
+
+Ideally, these changes will be included in Swift 5.3, with the "future language mode" parts tied to a frontend flag for testing, rather than a language version mode.
+
+## Source compatibility
+
+Significantly improved compared to SE-0274. Code that uses `#filePath` or `#fileID` will not be compilable in Swift 5.2 and earlier, but such code can continue to use `#file` until a future language version mode permits breaking changes.
+
+## Effect on ABI stability
+
+See SE-0274.
+
+## Effect on API resilience
+
+See SE-0274.
+
+## Alternatives considered
+
+The SE-0274 design was considered and accepted, but did not hold up to real-world use.
+
+In future language version modes, we could deprecate `#file` instead of `#fileID`, creating a situation where users must choose whether to update their uses of `#file` to either `#fileID` or `#filePath`. This would prompt future users to make a choice of behavior, but we don't want to force those users to make an explicit choice; we continue to believe that the concise file string (i.e. `#fileID` string) is the right choice for most uses.
+
+Similarly, we could simply introduce `#fileID` and change the standard library to use it, without adding `#filePath` or changing `#file`'s behavior. But since we think the `#fileID` string is the right default, this would leave us with a design that encouraged the wrong defaults.
+
+We could remove the `#fileID` syntax from this proposal, probably retaining it in underscored form as an implementation detail used to transition the standard library assertions to the new strings in Swift 5 mode. This would give us a cleaner "Swift 6 mode" without a deprecated `#fileID` hanging around, but we don't want to keep potential adopters outside the standard library from gaining the advantages of the new strings if they want them.
+
+There are many colors other than `#fileID` that we could use to paint this bikeshed; we like this spelling because it's shorter than `#filePath` and suitably vague about the exact format of the string it produces.
diff --git a/proposals/0286-forward-scan-trailing-closures.md b/proposals/0286-forward-scan-trailing-closures.md
new file mode 100644
index 0000000000..972038c5a6
--- /dev/null
+++ b/proposals/0286-forward-scan-trailing-closures.md
@@ -0,0 +1,343 @@
+# Forward-scan matching for trailing closures
+
+* Proposal: [SE-0286](0286-forward-scan-trailing-closures.md)
+* Author: [Doug Gregor](https://github.com/DougGregor)
+* Review Manager: [John McCall](https://github.com/rjmccall)
+* Status: **Implemented (Swift 5.3)**
+* Upcoming Feature Flag: `ForwardTrailingClosures` (implemented in Swift 5.8)
+* Implementation: [apple/swift#33092](https://github.com/apple/swift/pull/33092)
+* Toolchains: [Linux](https://ci.swift.org/job/swift-PR-toolchain-Linux/404//artifact/branch-master/swift-PR-33092-404-ubuntu16.04.tar.gz), [macOS](https://ci.swift.org/job/swift-PR-toolchain-osx/579//artifact/branch-master/swift-PR-33092-579-osx.tar.gz)
+* Discussion: ([Pitch #1](https://forums.swift.org/t/pitch-1-forward-scan-matching-for-trailing-closures-source-breaking/38162)), ([Pitch #2](https://forums.swift.org/t/pitch-2-forward-scan-matching-for-trailing-closures/38491))
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/07bcb908125e1795a08d47391b5d866eb782639e/proposals/0286-forward-scan-trailing-closures.md)
+* Review: ([Review](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529)), ([Acceptance](https://forums.swift.org/t/accepted-with-modifications-se-0286-forward-scan-for-trailing-closures/38836))
+
+## Introduction
+
+[SE-0279 "Multiple Trailing Closures"](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md) 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.
+
+However, the backward-scan matching rule makes it hard to write good API that uses trailing closures, especially multiple trailing closures. This proposal replaces the backward scan with a forward scan wherever possible, which is simpler, more in line with normal argument matching in a call, and works better for APIs that support trailing closures (whether single or multiple) and default arguments. This change introduces a *minor source break* for code involving multiple, defaulted closure parameters, but that source break is staged over multiple Swift versions.
+
+## Motivation
+
+Several folks noted the downsides of the "backward" matching rule. The rule itself is described in the [detailed design](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md#detailed-design) section of SE-0279 (search for "backward"). To understand the problem with the backward rule, let's try to declare the UIView [`animate(withDuration:animations:completion:)`](https://developer.apple.com/documentation/uikit/uiview/1622515-animate) method in the obvious way to make use of SE-0279:
+
+```swift
+class func animate(
+ withDuration duration: TimeInterval,
+ animations: @escaping () -> Void,
+ completion: ((Bool) -> Void)? = nil
+)
+```
+
+SE-0279 matches the named trailing closure arguments backward, matching the last (labeled) trailing closure argument from the back of the parameter list, then proceeding to move to earlier trailing closures and function parameters. Consider the following example (straight from SE-0279):
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+} completion: { _ in
+ self.view.removeFromSuperview()
+}
+```
+
+The `completion:` trailing closure matches the last parameter, and the unnamed trailing closure matches `animations:`. The backward rule worked fine here.
+
+However, things fall apart when a single (therefore unnamed) trailing closure is provided to this API:
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+}
+```
+
+Now, the backward rule matches the unnamed trailing closure to `completion:`. The compiler produces an error:
+
+```
+error: missing argument for parameter 'animations' in call
+ animate(withDuration: 0.3) {
+```
+
+Note that the "real" UIView API actually has two different methods---`animate(withDuration:animations:completion:)` and `animate(withDuration:animations:)`---where the latter looks like this:
+
+```swift
+class func animate(
+ withDuration duration: TimeInterval,
+ animations: @escaping () -> Void
+)
+```
+
+This second overload only has a closure argument, so the backward-matching rule handles the single-trailing-closure case. These overloads exist because these UIView APIs were imported from Objective-C, which does not have default arguments. A new Swift API would not be written this way---except that SE-0279 forces it due to the backward-matching rule.
+
+## Proposed solution
+
+The idea of the forward-scan matching rule is to match trailing closure arguments to parameters in the same forward, left-to-right manner that other arguments are matched to parameters. The unlabeled trailing closure will be matched to the next parameter that is either unlabeled or has a declared type that structurally resembles a function type (defined below). For the example above, this means the following:
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+}
+// equivalent to
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+})
+```
+
+and
+
+```swift
+UIView.animate(withDuration: 0.3) {
+ self.view.alpha = 0
+} completion: { _ in
+ self.view.removeFromSuperview()
+}
+// equivalent to
+UIView.animate(withDuration: 0.3, animations: {
+ self.view.alpha = 0
+}, completion: { _ in
+ self.view.removeFromSuperview()
+})
+```
+
+Note that the unlabeled trailing closure matches `animations:` in both cases; specifying additional trailing closures fills out later parameters but cannot shift the unlabeled trailing closure to an earlier parameter.
+
+Note that you can still have the unlabeled trailing closure match a later parameter, by specifying earlier ones:
+
+```swift
+UIView.animate(withDuration: 0.3, animations: self.doAnimation) { _ in
+ self.view.removeFromSuperview()
+}
+// equivalent to
+UIView.animate(withDuration: 0.3, animations: self.doAnimation, completion: { _ in
+ self.view.removeFromSuperview()
+})
+```
+
+This is both a consequence of forward matching and also a necessity for source compatibility.
+
+### Structural resemblance to a function type
+
+When a function parameter does not require an argument (e.g., because it is variadic or has a default argument), the call site can skip mentioning that parameter entirely, and the default will be used instead (e.g., an empty variadic argument or the specified default argument). The matching of arguments to parameters tends to rely on argument labels to determine when a particular parameter has been skipped. For example:
+
+```swift
+func nameMatchingExample(x: Int = 1, y: Int = 2, z: Int = 3) { }
+
+nameMatchingExample(x: 5) // equivalent to nameMatchingExample(x: 5, y: 2, z: 3)
+nameMatchingExample(y: 4) // equivalent to nameMatchingExample(x: 1, y: 4, z: 3)
+nameMatchingExample(x: -1, z: -3) // equivalent to nameMatchingExample(x: -1, y: 2, z: -3)
+```
+
+The unlabeled trailing closure ignores the (otherwise required) argument label, which would prevent the use of argument labels for deciding which parameter should be matched with the unlabeled trailing closure. Let's bring that back to the UIView example by adding a default argument to `withDuration:`
+
+```swift
+class func animate(
+ withDuration duration: TimeInterval = 1.0,
+ animations: @escaping () -> Void,
+ completion: ((Bool) -> Void)? = nil
+)
+```
+
+Consider a call:
+
+```swift
+UIView.animate {
+ self.view.alpha = 0
+}
+```
+
+The first parameter is `withDuration`, but there is no argument in parentheses. Unlabeled trailing closures ignore the parameter name, so without some additional rule, the unlabeled trailing closure would try to match `withDuration:` and this call would be ill-formed.
+
+The forward-scan matching rule skips over any parameters that do not "structurally resemble" a function type. A parameter structurally resembles a function type if both of the following are true:
+
+* The parameter is not `inout`
+* The adjusted type of the parameter (defined below) is a function type
+
+The adjusted type of the parameter is the parameter's type as declared in the function, looking through any type aliases whenever they appear, and performing three adjustments:
+
+* If the parameter is an `@autoclosure` , use the result type of the parameter's declared (function) type, before performing the second adjustment.
+* If the parameter is variadic, looking at the element type of the (implied) array type.
+* Remove all outer "optional" types.
+
+Following this rule, the `withDuration` parameter (a `TimeInterval`) does not resemble a function type. However, `@escaping () -> Void` does, so the unlabeled trailing closure matches `animations`. `@autoclosure () -> ((Int) -> Int)` and `((Int) -> Int)?` would also resemble a function type.
+
+### Mitigating the source compatibility impact (all language versions)
+
+The forward-scanning rule, as described above, is source-breaking. A run over Swift's [source compatibility suite](https://swift.org/source-compatibility/) with this change enabled in all language modes turned up source compatibility breaks in three projects. The first problem occurs with a SwiftUI API [`View.sheet(isPresented:onDismiss:content:)`](https://developer.apple.com/documentation/swiftui/view/sheet(ispresented:ondismiss:content:)):
+
+```swift
+func sheet(
+ isPresented: Binding,
+ onDismiss: (() -> Void)? = nil,
+ content: @escaping () -> Content
+) -> some View
+```
+
+Note that `onDismiss` and `content` both structurally resemble a function type. This API fits well with the backward-matching rule, because the unlabeled trailing closure in the following example is always ascribed to `content:`. The `onDismiss:` argument gets the default argument `nil`:
+
+```swift
+sheet(isPresented: $isPresented) { Text("Hello") }
+```
+
+With the forward-scanning rule, the unlabeled trailing closure matches the `onDismiss:` parameter, and there is no suitable argument for `content:`. Therefore, the well-formed code above would be rejected by the rule as proposed above.
+
+However, it is clear from the function signature that (1) `onDismiss:` could have used the default argument, and (2) `content:` therefore won't have an argument if it is not paired with the unlabeled trailing closure. We can turn this into an heuristic to accept more existing code, reducing the source breaking impact of the proposal. Specifically, if
+
+* the parameter that would match the unlabeled trailing closure
+argument does not require an argument (because it is variadic or has a default argument), and
+* there are parameters *after* that parameter that require an argument, up until the first parameter whose label matches that of the *next* trailing closure (if any)
+
+then do not match the unlabeled trailing closure to that parameter. Instead, skip it and examine the next parameter to see if that should be matched against the unlabeled trailing closure. For the `View.sheet(isPresented:onDismiss:content:)` API, this means that `onDismiss`, which has a default argument, will be skipped in the forward match so that the unlabeled trailing closure will match `content:`, allowing this code to continue to compile correctly.
+
+This heuristic is remarkably effective: in addition to fixing 2 of the 3 failures from the Swift source compatibility suite (the remaining failure will be discussed below), it resolved most of the failures we observed in a separate (larger) testsuite comprising a couple of million lines of Swift.
+
+One practical effect of this heuristic is that it makes the forward scan as proposed here produce the same results as the existing backward scan in many, many more cases.
+
+### Mitigating the source compatibility impact (Swift < 6)
+
+Even with the heuristic, the forward-scan matching rule will still fail to compile some existing code, and can change the meaning of some code, when there are multiple, defaulted parameters of closure type. As an example, the remaining source compatibility failure in the Swift source compatibility suite, a project called [ModelAssistant](https://github.com/ssamadgh/ModelAssistant), is due to [this API](https://github.com/ssamadgh/ModelAssistant/blob/c96335280a3aba5f8e14955ecaf38dc25a0872b6/Source/Libraries/AOperation/Observers/BlockObserver.swift#L22-L26):
+
+```swift
+init(
+ startHandler: ((AOperation) -> Void)? = nil,
+ produceHandler: ((AOperation, Foundation.Operation) -> Void)? = nil,
+ finishHandler: ((AOperation, [NSError]) -> Void)? = nil
+) {
+ self.startHandler = startHandler
+ self.produceHandler = produceHandler
+ self.finishHandler = finishHandler
+}
+```
+
+Note that this API takes three closure parameters. The (existing) backward scan will match `finishHandler:`, while the forward scan will match `startHandler:`. The heuristic described in the previous section does not apply, because all of the closure parameters have default arguments. Existing code that uses trailing closures with this API will break.
+
+Note that this API interacts poorly with SE-0279 multiple trailing closures, because the unlabeled trailing closure "moves" backwards as additional trailing closures are provided at the call site:
+
+```swift
+// SE-0279 backward scan behavior
+BlockObserver { (operation, errors) in
+ print("finishHandler!")
+}
+
+// label finishHandler, unlabeled moves "back" to produceHandler
+
+BlockObserver { (aOperation, foundationOperation) in
+ print("produceHandler!")
+} finishHandler: { (operation, errors) in
+ print("finishHandler!")
+}
+
+// label produceHandler, unlabeled moves "back" to startHandler
+BlockObserver { aOperation in
+ print("startHandler!")
+} produceHandler: { (aOperation, foundationOperation) in
+ print("produceHandler!")
+} finishHandler: { (operation, errors) in
+ print("finishHandler!")
+}
+```
+
+The forward scan provides a consistent unlabeled trailing closure anchor, and later (labeled) trailing closures can be tacked on:
+
+```swift
+// Proposed forward scan
+BlockObserver { aOperation in
+ print("startHandler!") {
+}
+
+// add another
+BlockObserver { aOperation in
+ print("startHandler!")
+} produceHandler: { (aOperation, foundationOperation) in
+ print("produceHandler!")
+}
+
+// specify everything
+BlockObserver { aOperation in
+ print("startHandler!")
+} produceHandler: { (aOperation, foundationOperation) in
+ print("produceHandler!")
+} finishHandler: { (operation, errors) in
+ print("finishHandler!")
+}
+
+// skip the middle one!
+BlockObserver { aOperation in
+ print("startHandler!")
+} finishHandler: { (operation, errors) in
+ print("finishHandler!")
+}
+```
+
+The forward-scan matching rule provides more predictable results, making it easier to understand how to use this API properly. However, maintaining backward compatibility requires that the backward scan be considered in places where it differs from the forward scan.
+
+To address this remaining source compatibility problem, Swift minor versions (prior to Swift 6) shall implement an additional rule for calls that involve a single (unlabeled) trailing closure. If the forward and backward-scan rules produce *different* assignments of arguments to parameters, then the Swift compiler will attempt both: if only one succeeds, use it. If both succeed, prefer the backward-scanning rule (for source compatibility reasons) and produce a warning about the use of the backward scan. For example:
+
+```swift
+BlockObserver { (operation, errors) in
+ print("finishHandler!")
+}
+```
+
+Here, the forward scan fails to type-check, because the closure accepts two parameters whereas `startHandler` accepts a single parameter. Therefore, the backward scan is selected, maintaining source compatibility, and produces a warning with a Fix-It to make the trailing closure a regular argument:
+
+```
+warning: backward matching of the unlabeled trailing closure is deprecated; label the argument with 'finishHandler' to suppress this warning
+BlockObserver { (operation, errors) in
+ ^
+ (finishHandler:
+```
+
+If there truly is an ambiguity, where both the forward scan and backward scan type-check but would do so differently, we prefer the backward scan to maintain source compatibility:
+
+```swift
+func trailingClosureBothDirections(
+ f: (Int, Int) -> Int = { $0 + $1 }, g: (Int, Int) -> Int = { $0 - $1 }
+) { }
+trailingClosureBothDirections { $0 * $1 }
+```
+
+Here, the forward scan would bind the trailing closure to `f:` (for Swift 6 and newer) while the backward scan would bind the trailing closure to `g:` (for Swift < 6). The same warning will apply when the backward scan result is chosen, with a Fix-It to rewrite the code to:
+
+```swift
+trailingClosureBothDirections(g: { $0 * $1 })
+```
+
+This suppresses the warning and eliminates the ambiguity, so the code behaves the same across all overload sets.
+
+The Swift 6 and newer behavior can be enabled in existing language modes with the [upcoming feature flag](0362-piecemeal-future-features.md) `ForwardTrailingClosures`.
+
+### Workaround via overload sets
+
+APIs like the above that depend on the backward scan can be reworked to provide the same client API. The basic technique involves removing the default arguments, then adding additional overloads to create the same effect. For example, drop the default argument of `finishHandler` so that the heuristic will kick in to fix calls with a single unlabeled trailing closure:
+
+```swift
+init(
+ startHandler: ((AOperation) -> Void)? = nil,
+ produceHandler: ((AOperation, Foundation.Operation) -> Void)? = nil,
+ finishHandler: ((AOperation, [NSError]) -> Void)?
+) {
+ self.startHandler = startHandler
+ self.produceHandler = produceHandler
+ self.finishHandler = finishHandler
+}
+```
+
+One can then add overloads to handle other cases, e.g., the zero-argument case:
+
+```swift
+init() {
+ self.init(startHandler: nil, produceHandler: nil, finishHandler: nil)
+}
+```
+
+## Future directions
+
+The proposal specifies that the "backward" scan be removed in Swift 6, which introduces a small source break that is staged in over time. However, the heuristic (that skips matching the unnamed trailing closure argument to a parameter that doesn't require an argument when the unnamed trailing closure is needed to match a later parameter) is retained. However, some future language version (Swift 6 or even later) might accept more source breakage by removing this heuristic---leaving only the forward scan in place---and find a better way to express APIs such as `View.sheet(isPresented:onDismiss:content:)` in the language. Possibilities include (but are not limited to):
+
+* A parameter attribute `@noTrailingClosure` that prevents the use of trailing closure syntax for a given parameter entirely.
+* Eliminating the allowance for matching the first (unlabeled) trailing closure to a parameter that has an argument label, so normal argument matching rules would apply.
+* Allowing an argument label on the first trailing closure to let the caller select which parameter to match explicitly.
+
+This proposal leaves open all of these possibilities, and makes their changes less drastic because each of the ideas involves moving to a forward-scan matching rule. As such, this proposal makes SE-0279's multiple trailing closures immediately useful with minimal (or no) source breakage, paving the way for more significant changes if we so choose in the future.
+
+## Revision history
+
+* **Version 2**: Improved source compatibility by performing both the forward and backward scans in Swift < 6 mode ([originally suggested](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529/9) by Pavel Yaskevich) and adopting the [specific proposal](https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529/30) from Xiaodi Wu to prefer the backward scan result in Swift < 6 when the two scans differ.
diff --git a/proposals/0287-implicit-member-chains.md b/proposals/0287-implicit-member-chains.md
new file mode 100644
index 0000000000..27fd9da22c
--- /dev/null
+++ b/proposals/0287-implicit-member-chains.md
@@ -0,0 +1,252 @@
+# Extend implicit member syntax to cover chains of member references
+
+* Proposal: [SE-0287](0287-implicit-member-chains.md)
+* Author: [Frederick Kellison-Linn](https://github.com/jumhyn)
+* Review Manager: [Doug Gregor](https://github.com/DougGregor)
+* Status: **Implemented (Swift 5.4)**
+* Implementation: [apple/swift#31679](https://github.com/apple/swift/pull/31679)
+* Review: [Review](https://forums.swift.org/t/se-0287-extend-implicit-member-syntax-to-cover-chains-of-member-references/39398), [Acceptance](https://forums.swift.org/t/accepted-se-0287-extend-implicit-member-syntax-to-cover-chains-of-member-references/39714)
+
+## Introduction
+
+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":
+
+```swift
+class C {
+ static let zero = C(0)
+ var x: Int
+
+ init(_ x: Int) {
+ self.x = x
+ }
+}
+
+func f(_ c: C) {
+ print(c.x)
+}
+
+f(.zero) // prints '0'
+```
+
+This allows for the omission of repetitive type information in contexts where the type information is already obvious to the reader:
+```swift
+view.backgroundColor = .systemBackground
+```
+
+This proposal suggests the expansion of implicit member syntax to more complex expressions than just a single static member or function. Specifically, implicit member syntax would be allowed to cover chains of member references.
+
+## Motivation
+
+Today, attempting to use implicit member syntax with a chain of member references fails:
+
+```swift
+extension C {
+ var incremented: C {
+ return C(self.x + 1)
+ }
+}
+
+f(.zero.incremented) // Error: Type of expression is ambiguous without more context
+```
+
+This error breaks the mental model that many users likely have for implicit member syntax, which boils down to a simple lexical omission of the type name in contexts where the type is clear. I.e., users expect that writing:
+
+```swift
+let one: C = .zero.incremented
+```
+
+is just the same as writing
+
+```swift
+let one = C.zero.incremented
+```
+
+This issue arises in practice with any type that offers "modifier" methods that vend updated instances according to some rule. For example, `UIColor` offers the `withAlphaComponent(_:)` modifier for constructing new colors, which cannot be used with implicit member syntax:
+
+```swift
+let milky: UIColor = .white.withAlphaComponent(0.5) // error
+```
+
+## Proposed solution
+
+Improve implicit member expression syntax to handle multiple chained member accesses. The base type of the implicit member expression would be constrained to match the contextual/resultant type of the whole chain. Under this proposal, all of the following would successfully typecheck:
+
+```swift
+let milky: UIColor = .white.withAlphaComponent(0.5)
+let milky2: UIColor = .init(named: "white")!.withAlphaComponent(0.5)
+let milkyChance: UIColor? = .init(named: "white")?.withAlphaComponent(0.5)
+
+struct Foo {
+ static var foo = Foo()
+
+ var anotherFoo: Foo { Foo() }
+ func getFoo() -> Foo { Foo() }
+ var optionalFoo: Foo? { Foo() }
+ var fooFunc: () -> Foo { { Foo() } }
+ var optionalFooFunc: () -> Foo? { { Foo() } }
+ var fooFuncOptional: (() -> Foo)? { { Foo() } }
+ subscript() -> Foo { Foo() }
+}
+
+let _: Foo = .foo.anotherFoo
+let _: Foo = .foo.anotherFoo.anotherFoo.anotherFoo.anotherFoo
+let _: Foo = .foo.getFoo()
+let _: Foo = .foo.optionalFoo!.getFoo()
+let _: Foo = .foo.fooFunc()
+let _: Foo = .foo.optionalFooFunc()!
+let _: Foo = .foo.fooFuncOptional!()
+let _: Foo = .foo.optionalFoo!
+let _: Foo = .foo[]
+let _: Foo = .foo.anotherFoo[]
+let _: Foo = .foo.fooFuncOptional!()[]
+
+struct Bar {
+ var anotherFoo = Foo()
+}
+
+extension Foo {
+ static var bar = Bar()
+ var anotherBar: Bar { Bar() }
+}
+
+let _: Foo = .bar.anotherFoo
+let _: Foo = .foo.anotherBar.anotherFoo
+```
+
+## Detailed design
+
+This proposal would provide the model mentioned earlier for implicit member expressions: anywhere that a contextual type `T` can be inferred, writing
+
+```swift
+.member1.member2.(...).memberN
+```
+
+Will behave as if the user had written:
+
+```swift
+T.member1.member2.(...).memberN
+```
+
+Note: if `T` is an optional type `R?` for some type `R`, we maintain the existing rule that lookup of `member1` in an implicit base will proceed in both `R?` and `R` (which allows the `milkyChance` example above to compile).
+
+Members of this "implicit member chain" can be any of the following:
+- Property references
+- Method calls
+- Forced unwrapping expressions
+- Optional-chaining question marks
+- Subscripts
+
+When any of the above is encountered by the type checker, it will determine two things:
+
+1. Whether this expression sits at the tail of the chain.
+2. Whether the base of the chain is an implicit member expression.
+
+If those two conditions are met, then a constraint is introduced requiring the result of the whole chain to equal the type of the base of the implicit member expression.
+
+Members of the chain are allowed to participate in generic parameter inference as well. Thus, the following code is valid:
+
+```swift
+struct Foo {
+ static var foo: Foo { Foo() }
+ var anotherFoo: Foo { Foo() }
+ func getAnotherFoo() -> Foo {
+ Foo()
+ }
+}
+
+extension Foo where T == Int {
+ static var fooInt: Foo { Foo() }
+ var anotherFooInt: Foo { Foo() }
+ var anotherFooIntString: Foo { Foo() }
+ func getAnotherFooInt() -> Foo {
+ Foo()
+ }
+}
+
+extension Foo where T == String {
+ var anotherFooStringInt: Foo { Foo() }
+}
+
+func implicit(_ arg: Foo) {}
+
+// T inferred as Foo in all of the following
+implicit(.fooInt)
+implicit(.foo.anotherFooInt)
+implicit(.foo.anotherFooInt.anotherFoo)
+implicit(.foo.anotherFoo.anotherFooInt)
+implicit(.foo.getAnotherFooInt())
+implicit(.foo.anotherFoo.getAnotherFooInt())
+implicit(.foo.getAnotherFoo().anotherFooInt)
+implicit(.foo.getAnotherFooInt())
+implicit(.foo.getAnotherFoo().getAnotherFooInt())
+// Members types along the chain can have different generic arguments
+implicit(.foo.anotherFooIntString.anotherFooStringInt)
+```
+
+If `T` is the contextually inferred type but `memberN` has non-convertible type `R` , a diagnostic of the form:
+
+```swift
+Error: Cannot convert value of type 'R' to expected type 'T'
+```
+
+will be produced. The exact form of the diagnostic will depend on how `T` was contextually inferred (e.g. as an argument, as an explicit type annotation, etc.).
+
+## Source compatibility
+
+This is a purely additive change and does not have any effect on source compatibility.
+
+## Effect on ABI stability
+
+This change is frontend only and would not impact ABI.
+
+## Effect on API resilience
+
+This is not an API-level change and would not impact resilience.
+
+## Alternatives considered
+
+### Require homogeneously-typed chains
+
+While overall discussion around this feature was very positive, one point of minor disagreement was whether chains should be required to have the same type along the length of the chain. Such a rule would prohibit constructs like this:
+
+```swift
+struct S {
+ static var foo = T()
+}
+
+struct T {
+ var bar = S()
+}
+
+let _: S = .foo.bar // error!
+```
+
+Proponents of this rule argued that the most common use case for these member chains (the aforementioned "modifier" or "builder" methods) doesn't require heterogeneously-typed chains, and that supporting them would introduce a cognitive load for readers of code that relies on heterogeneously-typed chains.
+
+A rule of this form was explored during implementation, but was abandoned for several reasons. One was simply that the implementation complexity would have been greatly increased in order to properly support the additional constraints along the chain while still offering helpful diagnostics. Another is that such a rule is far less flexible in situations that seem like they should work even with homogeneously-typed chains. For instance, allowing heterogeneously-typed chains easily enables the following syntax to compile:
+
+```swift
+struct HasClosure {
+ static var factoryOpt: ((Int) -> HasClosure)? = { _ in .init() }
+}
+
+var _: HasClosure = .factoryOpt!(4)
+```
+
+Trying to support this construction with "homogeneously-typed chains" rule in place would require significantly more interaction between the different segments of the chain in order to decide whether certain constructions should be allowed.
+
+Lastly, the author makes the subjective determination that such a rule would be at odds with the expectations of most users when using implicit member chains. Visually, implicit member chains appear very similar to keypath expressions, and indeed support all the same elements as keypath expressions (additionally supporting method/function calls). There is no such restriction that keypath expressions refer to the same type along their length (even when the keypath base type is omitted), so users may find it surprising that the compiler does not accept identical syntax for direct property accesses:
+
+```swift
+struct S {
+ static var foo = T()
+ var foo: T { T() }
+}
+
+struct T {
+ var bar = S()
+}
+
+let _: KeyPath = \.foo.bar
+let _: S = .foo.bar // error?
+```
diff --git a/proposals/0288-binaryinteger-ispower.md b/proposals/0288-binaryinteger-ispower.md
new file mode 100644
index 0000000000..b48fde326d
--- /dev/null
+++ b/proposals/0288-binaryinteger-ispower.md
@@ -0,0 +1,274 @@
+# Adding `isPower(of:)` to `BinaryInteger`
+
+* Proposal: [SE-0288](0288-binaryinteger-ispower.md)
+* Author: [Ding Ye](https://github.com/dingobye)
+* Review Manager: [Joe Groff](https://github.com/jckarter)
+* Status: **Previewing**
+* Implementation: [apple/swift#24766](https://github.com/apple/swift/pull/24766)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0288-adding-ispower-of-to-binaryinteger/40325)
+
+## Introduction
+
+Checking some mathematical properties of integers (e.g. parity, divisibility, etc.) is widely used in scientific and engineering applications. Swift brings a lot of convenience when performing such checks, thanks to the relevant methods (e.g. `isMultiple(of:)`) provided by the standard library. However there are still some other cases not yet supported. One of those useful checks that are currently missing is to tell if an integer is power of another, of which the implementation is non-trivial. Apart from inconvenience, user-implemented code can bring inefficiency, poor readability, and even incorrectness. To address this problem, this proposal would like to add a public API `isPower(of:)`, as an extension method, to the `BinaryInteger` protocol.
+
+Swift-evolution thread: [Pitch](https://forums.swift.org/t/adding-ispowerof2-to-binaryinteger/24087)
+
+
+## Motivation
+
+Checking whether an integer is power of a given base is a typical integral query in a wide range of applications, and is especially common when the base value is two. A question about [How to check if a number is a power of 2](https://stackoverflow.com/questions/600293/how-to-check-if-a-number-is-a-power-of-2) on Stack Overflow grows for a decade with ~200K views. Since there are public demands for such functionality, it has been or will be officially supported by the libraries of many popular languages, such as [C++20](https://en.cppreference.com/w/cpp/numeric/ispow2), [D Programming Language](https://dlang.org/library/std/math/is_power_of2.html), and [.NET Framework](https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger.ispoweroftwo?view=netframework-4.8).
+
+Swift, as a general-purpose programming language, is also experiencing such demands covering a variety of domains, including numerical and mathematical libraries (e.g. [#1](https://github.com/jsbean/ArithmeticTools/blob/cb6dae327baf53cdf614d26e630833efa00eda3f/ArithmeticTools/IntegerExtensions.swift#L48), [#2](https://github.com/Orbifold/XAct/blob/9acad78e5571aa93fb52d88f539459effab1d5f7/XAct/Numbers.swift#L49), [#3](https://github.com/donald-pinckney/SwiftNum/blob/b92e3b964268ebf62d99f488fcdf438574974f0d/Sources/SignalProcessing/IntExtensions.swift#L12), [#4](https://github.com/dn-m/Math/blob/d1284e043377c0b924cba2ffa2ab0b9aa9dd246f/Sources/Math/IntegerExtensions.swift#L48)), programming language and compiler components (e.g. [#1](https://github.com/kai-language/kai/blob/41268660a01e0d6d1f0ac8de743d91700707135e/Sources/Core/Helpers/Helpers.swift#L205), [#2](https://github.com/llvm-swift/LLVMSwift/blob/162f1632e017349b17146e33c5905f88148e55f1/Sources/LLVM/Units.swift#L125)), image/video manipulation (e.g. [#1](https://github.com/schulz0r/CoreImage-HDR/blob/c7f5264929338beebfcfbf2e420594aa2952ef6c/CoreImage-HDR/Convenience/extensions.swift#L20), [#2](https://github.com/OpsLabJPL/MarsImagesIOS/blob/f2109f38b31bf1ad2e7b5aae6916da07d2d7d08e/MarsImagesIOS/Math.swift#L17), [#3](https://github.com/chingf/CarmenaCamera/blob/bfa928ca1595770c3b99bb8aa95dc5340a0f3284/VideoCapture/Common.swift#L22), [#4](https://github.com/dehancer/IMProcessing/blob/7a7d48edb7ceeb2635219c8139aa6fb8dbf1525d/IMProcessing/Classes/Common/IMPNumericTypes.swift#L132)), and other applications and utilities such as [geography kit](https://github.com/tokyovigilante/CesiumKit/blob/7983bd742a85982d9c3303cdacc039dcb44c8a42/CesiumKit/Core/Math.swift#L597), [quantum circuit simulator](https://github.com/indisoluble/SwiftQuantumComputing/blob/008e82e0f38792372df1a428884cccb74c2732b3/SwiftQuantumComputing/Extension/Int%2BIsPowerOfTwo.swift#L24), [tournament](https://github.com/eaheckert/Tournament/blob/c09c6b3634da9b2666b8b1f8990ff62bdc4fd625/Tournament/Tournament/ViewControllers/TCreateTournamentVC.swift#L215), [blockchain](https://github.com/yeeth/BeaconChain.swift/blob/954bcb6e47b51f90eff16818719320a228afe891/Sources/BeaconChain/Extensions/Int.swift#L5), [3D-engine](https://github.com/xuzhao-nick/3DEngine/blob/c3aab94f2bce5e29f7988b0d7c1e075d74076ad7/3DEngine/3DEngine/MoreMath.swift#L50), etc.
+
+Apart from the *is-power-of-two* usage, queries on *non-2* bases may also be practical, though they are much less common. In signal processing, for example, the efficient radix-4 algorithms can be applied when the FFT size is a power of 4.
+
+As a result, it would be beneficial if we could have such an API supported in the standard library. To be more specific, it is an extension method in the form of `isPower(of:)` to the `BinaryInteger` protocol, checking whether the `BinaryInteger` *self* is a power of the base specified by the parameter. Let us discuss the impacts in the following aspects:
+
+### Readability
+
+A classic approach to check if an integer `n` is power of two is to test whether the condition `n > 0 && n & (n - 1) == 0` holds. Although such code is efficient, its underlying functionality is not intuitive to many people. As a result, programmers would have to put additional information somewhere (e.g. in the comments nearby) to make it clear.
+
+Below is an example when making an assertion that `bucketCount` is power of two. The classic approach is applied, followed by an additional error message for necessary clarification purpose. However, if we had the proposed API available, the code would become more fluent and concise.
+```swift
+// Example (1) - apple/swift/stdlib/public/core/HashTable.swift
+internal struct _HashTable {
+ internal init(words: UnsafeMutablePointer, bucketCount: Int) {
+ _internalInvariant(bucketCount > 0 && bucketCount & (bucketCount - 1) == 0,
+ "bucketCount must be a power of two")
+
+// _internalInvariant(bucketCount.isPower(of: 2)) --- proposed solution
+
+ ...
+ }
+}
+```
+
+### Efficiency
+
+The user-implemented code may be less performant (e.g. [#1](https://github.com/OpsLabJPL/MarsImagesIOS/blob/f2109f38b31bf1ad2e7b5aae6916da07d2d7d08e/MarsImagesIOS/Math.swift#L17), [#2](https://github.com/eaheckert/Tournament/blob/c09c6b3634da9b2666b8b1f8990ff62bdc4fd625/Tournament/Tournament/ViewControllers/TCreateTournamentVC.swift#L215)), since some developers are not aware of the classic approach as described above.
+
+The example below shows a controversial approach, which employs the `llvm.ctpop` intrinsic to count the number of 1 bits. It can be expensive when the hardware does not have relevant `popcount` instruction support.
+```swift
+// Example (2) - apple/swift/stdlib/public/core/Integers.swift
+extension BinaryInteger {
+ internal func _description(radix: Int, uppercase: Bool) -> String {
+ // Bit shifting can be faster than division when `radix` is a power of two
+ let isRadixPowerOfTwo = radix.nonzeroBitCount == 1
+ ...
+ }
+}
+```
+
+### Abstraction
+
+Some developers, especially those unfamiliar to the integer type hierarchy, may have their own implementation targeting inappropriate types.
+
+The following example presents very similar implementation individually for `UInt` and `Int`. Such code duplication could be avoided if it targeted `BinaryInteger`.
+```swift
+// Example (3) - apple/swift/stdlib/public/core/Misc.swift
+func _isPowerOf2(_ x: UInt) -> Bool {
+ // implementation
+}
+
+func _isPowerOf2(_ x: Int) -> Bool {
+ // implementation very similar to above
+}
+```
+
+### Discoverability
+
+IDEs can aid discoverability by suggesting `isPower(of:)` as part of autocompletion on integer types. Notably, it works as a companion to other existing integral query APIs (e.g. `isMultiple(of:)`), and they can help improve the discoverability of each other.
+
+
+## Proposed solution
+
+Our solution is to introduce a public API `isPower(of:)`, as an extension method, to the `BinaryInteger` protocol. It provides a standard implementation, which can be adopted by any type that conforms to this protocol. With regard to semantics, it returns `true` iff `self` is a power of the input `base`. To be more specific, it holds when (1) `self` is one (i.e., any base to the zero power), or (2) `self` equals the product of one or more `base`s. Note that this API sits at the `BinaryInteger` protocol level, and it is expected to properly handle negative integers when the type `Self` is signed.
+
+```swift
+// In the standard library
+extension BinaryInteger {
+ @inlinable public func isPower(of base: Self) -> Bool {
+ // implementation described in Detailed Design section
+ }
+}
+
+// In user code
+let x: Int = Int.random(in: 0000..<0288)
+1.isPower(of: x) // 'true' since x^0 == 1
+1000.isPower(of: 10) // 'true' since 10^3 == 1000
+(-1).isPower(of: 1) // 'false'
+(-32).isPower(of: -2) // 'true' since (-2)^5 == -32
+```
+
+
+## Detailed design
+
+A reference implementation can be found in [pull request #24766](https://github.com/apple/swift/pull/24766).
+
+### Overall Design
+
+To make the API efficient for most use cases, the implementation is based on a fast-/slow-path pattern. We presents a generic implementation, which is suitable for all inputs, as the slow path; and meanwhile provide some particularly optimized implementation for frequently used inputs (e.g. 2) individually as the fast paths. The high-level solution is illustrated below.
+
+```swift
+extension BinaryInteger {
+ @inlinable public func isPower(of base: Self) -> Bool {
+ // Fast path when base is one of the common cases.
+ if base == common_base_A { return self._isPowerOfCommonBaseA }
+ if base == common_base_B { return self._isPowerOfCommonBaseB }
+ if base == common_base_C { return self._isPowerOfCommonBaseC }
+ ...
+ // Slow path for other bases.
+ return self._slowIsPower(of: base)
+ }
+
+ @inlinable internal var _isPowerOfCommonBaseA: Bool { /* optimized implementation */ }
+ @inlinable internal var _isPowerOfCommonBaseB: Bool { /* optimized implementation */ }
+ @inlinable internal var _isPowerOfCommonBaseC: Bool { /* optimized implementation */ }
+ ...
+ @usableFromInline internal func _slowIsPower(of base: Self) -> Bool { /* generic implementation */ }
+}
+```
+Calling the public API `isPower(of: commonBaseK)` is expected to be as performant as directly calling the optimized version `_isPowerOfCommonBaseK`, if argument `commonBaseK` is a constant and the type `Self` is obvious enough (e.g. built-in integers) to the compiler to apply **constant-folding** to the `base == commonBaseK` expression, followed by a **simplify-cfg** transformation.
+
+### Fast path when base is two
+
+As for this fast path, it is **not** recommended to directly apply the classic approach to any type that conforms to `BinaryInteger` like this:
+```swift
+extension BinaryInteger {
+ @inlinable internal var _isPowerOfTwo: Bool {
+ return self > 0 && self & (self - 1) == 0
+ }
+}
+```
+Because when `Self` is some complicated type, the arithmetic, bitwise and comparison operations can be expensive and thus lead to poor performance. In this case, the `BinaryInteger.words`-based implementation below is preferred, where word is supported by the hardware and the operations are expected to be efficient.
+```swift
+extension BinaryInteger {
+ @inlinable internal var _isPowerOfTwo: Bool {
+ let words = self.words
+ guard !words.isEmpty else { return false }
+
+ // If the value is represented in a single word, perform the classic check.
+ if words.count == 1 {
+ return self > 0 && self & (self - 1) == 0
+ }
+
+ // Return false if it is negative. Here we only need to check the most
+ // significant word (i.e. the last element of `words`).
+ if Self.isSigned && Int(bitPattern: words.last!) < 0 {
+ return false
+ }
+
+ // Check if there is exactly one non-zero word and it is a power of two.
+ var found = false
+ for word in words {
+ if word != 0 {
+ if found || word & (word - 1) != 0 { return false }
+ found = true
+ }
+ }
+ return found
+ }
+}
+```
+
+### Fast path when base itself is a power of two
+
+As long as we have `_isPowerOfTwo` available, it becomes easy to implement such fast path when the base itself is power of two. It takes advantages of the existing APIs `isMultiple(of:)` and `trailingZeroBitCount`. The code can be written as below.
+
+```swift
+extension BinaryInteger {
+ @inlinable internal func _isPowerOf(powerOfTwo base: Self) -> Bool {
+ _precondition(base._isPowerOfTwo)
+ guard self._isPowerOfTwo else { return false }
+ return self.trailingZeroBitCount.isMultiple(of: base.trailingZeroBitCount)
+ }
+}
+```
+
+### Fast path when base is ten
+
+Unfortunately, there isn't any known super efficient algorithm to test if an integer is power of ten. Some optimizations are discussed in the forum to help boost the performance to some extent. Since the optimizations are conceptually non-trivial, they are not described here. Please refer to the [pitch thread](https://forums.swift.org/t/adding-ispowerof2-to-binaryinteger/24087/38) for details.
+
+
+### Slow path
+
+The slow path is generic for any input base, and the algorithm is standard. It handles some corner cases when `base.magnitude <= 1` in the first place; and then it repeatedly multiplies `base` to see if it can be equal to `self` at some point. Attentions are required to avoid overflow of the multiplications.
+
+```swift
+extension BinaryInteger {
+ @usableFromInline internal func _slowIsPower(of base: Self) -> Bool {
+ // If self is 1 (i.e. any base to the zero power), return true.
+ if self == 1 { return true }
+
+ // Here if base is 0, 1 or -1, return true iff self equals base.
+ if base.magnitude <= 1 { return self == base }
+
+ // At this point, we have base.magnitude >= 2. Repeatedly perform
+ // multiplication by a factor of base, and check if it can equal self.
+ let (bound, remainder) = self.quotientAndRemainder(dividingBy: base)
+ guard remainder == 0 else { return false }
+ var x: Self = 1
+ while x.magnitude < bound.magnitude { x *= base }
+ return x == bound
+ }
+}
+```
+
+## Source compatibility
+
+The proposed solution is an additive change.
+
+## Effect on ABI stability
+
+The proposed solution is an additive change.
+
+
+## Effect on API resilience
+
+The proposed solution is an additive change.
+
+
+## Alternatives considered
+
+### `isPower(of:)` as a protocol requirement
+
+Making the public API as a protocol requirement instead of an extension methods reserves future flexibility. It can give users a chance to provide their own optimization on some custom types where the default implementation is inefficient. However, it would increase the interface complexity of the heavily-used `BinaryInteger` protocol, so it may not be worthy.
+
+### `isPowerOfTwo` instead of `isPower(of:)`
+
+In fact, [the pitch](https://forums.swift.org/t/adding-ispowerof2-to-binaryinteger/24087) originally intended to add an API to check if an integer is power of two only. However, the more generic form `isPower(of:)` is favored by the community. This case is similar to [SE-0225](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md), which initially proposed `isEven` and `isOdd` as well, but ended up with `isMultiple(of:)` accepted only.
+
+### Choices for fast paths
+
+In the Detailed Design section, there are three specific cases of fast paths presented. Of course, we can have other choices. The fast path for base two is essential, since it is the most common case in real world applications and should always be kept as a fast path. We may remove the fast path for base ten if it is considered introducing too much complexity to the standard library.
+
+### Alternative optimizations for `_isPowerOfTwo`
+
+Apart from the classic approach, there are other optimization schemes to check if an integer is power of two. Two candidates are `ctpop`-based and `cttz`-based approaches, whose implementation is shown below.
+
+```swift
+extension FixedWidthInteger {
+ internal var _isPowerOfTwo_ctpop: Bool {
+ return self > 0 && self.nonzeroBitCount == 1
+ }
+}
+
+extension BinaryInteger {
+ internal var _isPowerOfTwo_cttz: Bool {
+ return (self > 0) && (self == (1 as Self) << self.trailingZeroBitCount)
+ }
+}
+```
+As per [the experimental results](https://github.com/apple/swift/pull/24766#issuecomment-492237146), they are overall less performant than the proposed solution on the types and platforms tested. In addition, the `ctpop`-based approach narrows down the scope from `BinaryInteger` to `FixedWidthInteger`.
+
+## Acknowledgments
+
+This proposal has been greatly improved by the community. Below are some cases of significant help.
+
+- Steve Canon followed the pitch all the way through and provided a lot of valuable comments to keep the work on the right track.
+- Jens Persson showed some inspiration in [an earlier thread](https://forums.swift.org/t/even-and-odd-integers/11774/117), and discussed some use cases as well as its extendability to floating point types.
+- Nevin Brackett-Rozinsky gave many details to optimize the implementation, and discovered [SR-10657](https://bugs.swift.org/browse/SR-10657) during the discussion.
+- Michel Fortin provided an efficient solution to the fast path for base 10 (i.e. checking if an integer is power of ten), together with thorough explanation.
+- Jordan Rose gave prompt and continued comments on the PR, and advised the API should better be an extension method rather than a protocol requirement.
+- Erik Strottmann suggested a more appropriate naming `_isPowerOfTwo` instead of `_isPowerOf2`.
+- Antoine Coeur had valuable discussions.
diff --git a/proposals/0289-result-builders.md b/proposals/0289-result-builders.md
new file mode 100644
index 0000000000..2e6a4fdef6
--- /dev/null
+++ b/proposals/0289-result-builders.md
@@ -0,0 +1,1270 @@
+# Result builders
+
+* Proposal: [SE-0289](0289-result-builders.md)
+* Authors: [John McCall](https://github.com/rjmccall), [Doug Gregor](https://github.com/DougGregor)
+* Review Manager: [Saleem Abdulrasool](https://github.com/compnerd)
+* Status: **Implemented (Swift 5.4)**
+* Previous Revisions: [1st](https://github.com/swiftlang/swift-evolution/blob/51c99447562e749b23f82184c99c0ddfb07a71df/proposals/0289-function-builders.md)
+
+Table of Contents
+=================
+ * [Result builders](#result-builders)
+ * [Changes from the first revision](#changes-from-the-first-revision)
+ * [Introduction](#introduction)
+ * [Motivation](#motivation)
+ * [Detailed design](#detailed-design)
+ * [Result builder types](#result-builder-types)
+ * [Result builder attributes](#result-builder-attributes)
+ * [Result-building methods](#result-building-methods)
+ * [The result builder transform](#the-result-builder-transform)
+ * [Statement blocks](#statement-blocks)
+ * [Declaration statements](#declaration-statements)
+ * [Expression statements](#expression-statements)
+ * [Assignments](#assignments)
+ * [Selection statements](#selection-statements)
+ * [Imperative control-flow statements](#imperative-control-flow-statements)
+ * [Exception-handling statements](#exception-handling-statements)
+ * [do statements](#do-statements)
+ * [for..in loops](#forin-loops)
+ * [Compiler Diagnostic Directives](#compiler-diagnostic-directives)
+ * [Availability](#availability)
+ * [Example](#example)
+ * [Type inference](#type-inference)
+ * [Result builder bodies](#result-builder-bodies)
+ * [Inferring result builders from protocol requirements](#inferring-result-builders-from-protocol-requirements)
+ * [Implicit memberwise initializer](#implicit-memberwise-initializer)
+ * [Source compatibility](#source-compatibility)
+ * [Effect on ABI stability and API resilience](#effect-on-abi-stability-and-api-resilience)
+ * [Future Directions](#future-directions)
+ * ["Simple" result builder protocol](#simple-result-builder-protocol)
+ * [Stateful result builders](#stateful-result-builders)
+ * [Transforming declarations](#transforming-declarations)
+ * [Virtualized Abstract Syntax Trees (ASTs)](#virtualized-abstract-syntax-trees-asts)
+ * [Alternatives considered](#alternatives-considered)
+ * [Additional control-flow statements](#additional-control-flow-statements)
+ * [Builder-scoped name lookup](#builder-scoped-name-lookup)
+ * [Dropping Void/Never values](#dropping-voidnever-values)
+
+## Changes from the first revision
+
+* The feature is now called *result builders* (rather than "function builders"). James Dempsey provided some [exploration and rationale](https://forums.swift.org/t/se-0289-function-builders/39889/75) for naming that led to this choice.
+* Although not part of the proposal itself, the [implementation quality has been improved](https://github.com/apple/swift/pull/33972) to help guide users in writing their result builders, with code completions and Fix-Its to help define the builder methods.
+* Added a section on [dropping `Void`/`Never` values](#dropping-voidnever-values) to the list of alternatives considered.
+* Clarified the role of each of the [result-building methods](#result-building-methods), and provided declarations for each that are easier to understand and copy/paste.
+
+## Introduction
+
+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.
+
+The basic idea is that the results of the function's statements are collected using a builder type, like so:
+
+```swift
+// Original source code:
+@TupleBuilder
+func build() -> (Int, Int, Int) {
+ 1
+ 2
+ 3
+}
+
+// This code is interpreted exactly as if it were this code:
+func build() -> (Int, Int, Int) {
+ let _a = TupleBuilder.buildExpression(1)
+ let _b = TupleBuilder.buildExpression(2)
+ let _c = TupleBuilder.buildExpression(3)
+ return TupleBuilder.buildBlock(_a, _b, _c)
+}
+```
+
+In this example, all the statements are expressions and so produce a single value apiece. Other statements, like `let`, `if`, and `while`, are variously either handled differently or prohibited; see the proposal details below.
+
+In effect, this proposal allows the creation of a new class of embedded domain-specific languages in Swift by applying *builder transformations* to the statements of a function. The power of these builder transformations is intentionally limited so that the result preserves the dynamic semantics of the original code: the original statements of the function are still executed as normal, it's just that values which would be ignored under normal semantics are in fact collected into the result. The use of an *ad hoc* protocol for the builder transformation leaves room for a wide variety of future extension, whether to support new kinds of statements or to customize the details of the transformation. A similar builder pattern was used successfully for string interpolation in [SE-0228](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0228-fix-expressiblebystringinterpolation.md).
+
+Result builders have been a "hidden" feature since Swift 5.1, under the name "function builder", and the implementation (and its capabilities) have evolved since then. They are used most famously by [SwiftUI](https://developer.apple.com/xcode/swiftui/) to declaratively describe user interfaces, but others have also experimented with [building Swift syntax trees](https://swiftpack.co/package/akkyie/SyntaxBuilder), [testing](https://www.dotconferences.com/2020/02/kaya-thomas-swift-techniques-for-testing),
+[a Shortcuts DSL](https://github.com/a2/swift-shortcuts), [a CSS DSL](https://github.com/carson-katri/swift-css/blob/master/Sources/CSS/CSSBuilder.swift), and [an alternative SwiftPM manifest format](https://forums.swift.org/t/declarative-package-description-for-swiftpm-using-function-builders/28699). There's a GitHub repository dedicated to [awesome function builders](https://github.com/carson-katri/awesome-function-builders) with more applications.
+
+## Motivation
+
+It's always been a core goal of Swift to allow the creation of great libraries. A lot of what makes a library great is its interface, and Swift is designed with rich affordances for building expressive, type-safe interfaces for libraries. In some cases, a library's interface is distinct enough and rich enough to form its own miniature language within Swift. We refer to this as a *Domain Specific Language* (DSL), because it lets you better describe solutions within a particular problem domain.
+
+Result builders target a specific kind of interface that involves the declaration of list and tree structures, which are useful in many problem domains, including generating structured data (e.g. XML or JSON), UI view hierarchies (notably including Apple's SwiftUI framework, mentioned above), and similar use cases. In this proposal, we will be primarily working with code which generates an HTML DOM hierarchy, somewhat like a web templating language except in code; credit goes to Harlan Haskins for this example.
+
+Suppose that you have a program, part of which generates HTML. You could, of course, directly generate a `String`, but that's error-prone (you have to make sure you're handling escapes and closing tags correctly throughout your code) and would make it hard to structurally process the HTML before sending it out. An alternative approach is to generate a DOM-like representation of the HTML and then render it to a `String` as a separate pass:
+
+
+```swift
+protocol HTML {
+ func renderAsHTML(into stream: HTMLOutputStream)
+}
+
+extension String: HTML {
+ func renderAsHTML(into stream: HTMLOutputStream) {
+ stream.writeEscaped(self)
+ }
+}
+
+struct HTMLNode: HTML {
+ var tag: String
+ var attributes: [String: String] = [:]
+ var children: [HTML] = []
+
+ func renderAsHTML(into stream: HTMLOutputStream) {
+ stream.write("<")
+ stream.write(tag)
+ for (k, v) in attributes.sort { $0.0 < $1.0 } {
+ stream.write(" ")
+ stream.write(k)
+ stream.write("=")
+ stream.writeDoubleQuoted(v)
+ }
+ if children.isEmpty {
+ stream.write("/>")
+ } else {
+ stream.write(">")
+ for child in children {
+ child.renderAsHTML(into: stream)
+ }
+ stream.write("")
+ }
+ }
+}
+```
+
+To make it easier to build these HTML hierarchies, we can define a bunch of convenient node-builder functions corresponding to common nodes:
+
+```swift
+func body(_ children: [HTML]) -> HTMLNode { ... }
+func division(_ children: [HTML]) -> HTMLNode { ... }
+func paragraph(_ children: [HTML]) -> HTMLNode { ... }
+func header1(_ text: String) -> HTMLNode { ... }
+```
+
+Unfortunately, even with these helper functions, it's still pretty awkward to actually produce a complex hierarchy because of all the lists of children:
+
+```swift
+return body([
+ division([
+ header1("Chapter 1. Loomings."),
+ paragraph(["Call me Ishmael. Some years ago"]),
+ paragraph(["There is now your insular city"])
+ ]),
+ division([
+ header1("Chapter 2. The Carpet-Bag."),
+ paragraph(["I stuffed a shirt or two"])
+ ])
+])
+```
+
+The first problem is that there's a lot of punctuation here: commas, parentheses, and brackets. This is a pretty superficial problem, and it's probably not a showstopper by itself, but it is something that it'd be nice to avoid, because it does distract a little from the content.
+
+The second problem is that, because we're using array literals for the children, the type-checker is going to require the elements to have a homogeneous type. That's fine for our HTML example, but it's limiting in general, because some trees are more generic and would benefit from propagating the types of the children into the type of the node. For example, SwiftUI uses this for various optimizations within the view hierarchy.
+
+The biggest problem, though, is that it's awkward to change the structure of this hierarchy. That's fine if our hierarchy is just the static contents of *Moby Dick*, but in reality, we're probably generating HTML that should vary significantly based on dynamic information. For example, if we wanted to allow chapter titles to be turned off in the output, we'd have to restructure that part of the code like this:
+
+```swift
+division((useChapterTitles ? [header1("Chapter 1. Loomings.")] : []) +
+ [paragraph(["Call me Ishmael. Some years ago"]),
+ paragraph(["There is now your insular city"])])
+```
+
+It's also harder to use good coding practices within this hierarchy. For example, suppose there's a common string we want to use many times, and so we want to create a variable for it:
+
+```swift
+let chapter = spellOutChapter ? "Chapter " : ""
+ ...
+header1(chapter + "1. Loomings.")
+ ...
+header1(chapter + "2. The Carpet-Bag.")
+```
+
+Most programmers would advise declaring this variable in as narrow a scope as possible, and as close as possible to where it's going to be used. But because the entire hierarchy is an expression, and there's no easy way to declare variables within expressions, every variable like this has to be declared above the entire hierarchy. (Now, it's true that there's a trick for declaring locals within expressions: you can start a closure, which gives you a local scope that you can use to declare whatever you want, and then immediately call it. But this is awkward in its own way and significantly adds to the punctuation problem.)
+
+Some of these problems would be solved, at least in part, if the hierarchy was built up by separate statements:
+
+```swift
+let chapter = spellOutChapter ? "Chapter " : ""
+
+let d1header = useChapterTitles ? [header1(chapter + "1. Loomings.")] : []
+let d1p1 = paragraph(["Call me Ishmael. Some years ago"])
+let d1p2 = paragraph(["There is now your insular city"])
+let d1 = division(d1header + [d1p1, d1p2])
+
+let d2header = useChapterTitles ? [header1(chapter + "2. The Carpet-Bag.")] : []
+let d2p1 = paragraph(["I stuffed a shirt or two"])
+let d2 = division(d2header + [d2p1])
+
+return body([d1, d2])
+```
+
+But in most ways, this is substantially worse. There's quite a lot of extra code that's made it much more difficult to track what's really going on. That's especially true with all the explicit data flow, where it can be tough to piece together what nodes are children of others; moreover, that code is as tedious to write as it is to read, making it very prone to copy-paste bugs. Furthermore, the basic structure of the hierarchy used to be clear from the code, and that's been completely lost: all of the nicely-nested calls to node builders have been flattened into one sequence. Also, while optional children are a common problem for this hierarchy, the actual code to handle them has to be repeated over and over again, leading to boilerplate and bugs. Overall, this is not a good approach at all.
+
+What we really want is a compromise between these two approaches:
+
+* We want the programming flexibility that comes from building things up with ordinary blocks of code: the ability to have local declarations and explicit control flow.
+
+* We want the explicit recursive structure and implicit data flow that comes from building things up with expression operands.
+
+This suggests a straightforward resolution: allow certain blocks of code to have implicit data flow out of the block and into the context which entered the block. The goal here is to allow this node hierarchy to be declared something like this:
+
+```swift
+return body {
+ let chapter = spellOutChapter ? "Chapter " : ""
+ division {
+ if useChapterTitles {
+ header1(chapter + "1. Loomings.")
+ }
+ paragraph {
+ "Call me Ishmael. Some years ago"
+ }
+ paragraph {
+ "There is now your insular city"
+ }
+ }
+ division {
+ if useChapterTitles {
+ header1(chapter + "2. The Carpet-Bag.")
+ }
+ paragraph {
+ "I stuffed a shirt or two"
+ }
+ }
+}
+```
+
+The above has to be embedded into the ordinary language somehow, which means that at least the outermost layer must obey something like ordinary language rules. Under ordinary language rules, this is a function call to `body` passing a trailing closure. It makes sense, then, that what we're doing is taking the body of the anonymous function and applying some sort of transformation to it. This raises a series of separate questions:
+
+1. What is it about this source code that triggers the transformation? We have chosen not to require an explicit annotation on every closure that needs transformation; see Alternatives Considered for a discussion. So somehow this must get picked up from the fact that we're passing the closure to `body`.
+
+2. Given that the transformation is going to collect a bunch of information, how does that information get back to `body`? Since the transformation is working on a function body, this one's straightforward: the collected information will just be the return value of the function. There's no requirement to support this transformation simultaneously with ordinary `return`.
+
+3. Given that the transformation has collected a sequence of partial results, how do they get combined to produce a return value? We could simply always produce a tuple, but that isn't necessarily what the caller actually wants. In particular, it may be useful to allow the DSL to do different things for different partial results. The logical answer is that there should be a function somehow provided by the DSL to combine the partial results, and this function might need to be generic or overloaded.
+
+4. Given that the transformation might collect a partial result within optionally-executed code (e.g. in an `if` statement), what should be passed to the combining function? The transformation can be taught to produce an optional value of the partial result type, but the DSL needs to be able to distinguish between a partial result that is optionally produced and a partial result that coincidentally happens to be of optional type. The logical answer is that there should be a function provided by the DSL to translate optional partial results into "ordinary" partial results that can be collected normally.
+
+These last two points (and some other considerations) strongly suggest that the DSL should be identified with a type that can provide an arbitrary namespace of functions that can be used as *ad hoc* customization points for the transformation.
+
+## Detailed design
+
+[SE-0258](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0258-property-wrappers.md) introduced the concept of custom attributes to Swift, an approach we build on here.
+
+### Result builder types
+
+A *result builder type* is a type that can be used as a result builder, which is to say, as an embedded DSL for collecting partial results from the expression-statements of a function and combining them into a return value.
+
+A result builder type must satisfy two basic requirements:
+
+* It must be annotated with the `@resultBuilder` attribute, which indicates that it is intended to be used as a result builder type and allows it to be used as a custom attribute.
+
+* It must supply at least one static `buildBlock` result-building method.
+
+In addition, it may supply a sufficient set of other result-building methods to translate the kinds of functions which the DSL desires to translate.
+
+### Result builder attributes
+
+A result builder type can be used as an attribute in two different syntactic positions. The first position is on a `func`, `var`, or `subscript` declaration. For the `var` and `subscript`, the declaration must define a getter, and the attribute is treated as if it were an attribute on that getter. A result builder attribute used in this way causes the result builder transform to be applied to the body of the function; it is not considered part of the interface of the function and does not affect its ABI.
+
+A result builder type can also be used as an attribute on a parameter of function type, including on parameters of protocol requirements. A result builder attribute used in this way causes the result builder transform to be applied to the body of any explicit closures that are passed as the corresponding argument, unless the closure contains a `return` statement. This is considered part of the interface of the function and can affect source compatibility, although it does not affect its ABI.
+
+### Result-building methods
+
+To be useful as a result builder, the result builder type must provide a sufficient subset of the result-building methods. The protocol between the compiler's generated code and the result builder type is intended to be *ad hoc* and arbitrarily extensible in the future.
+
+Result-building methods are `static` methods that can be called on the result builder type. Calls to result-building methods are type-checked as if a programmer had written `BuilderType.()`, where the arguments (including labels) are as described below; therefore, all the ordinary overload resolution rules apply. However, in some cases the result builder transform changes its behavior based on whether a result builder type declares a certain method at all; it is important to note that this is a weaker check, and it may be satisfied by a method that cannot in fact ever be successfully called on the given builder type.
+
+This is a quick reference for the result-building methods currently proposed. The typing here is subtle, as it often is in macro-like features. In the following descriptions, `Expression` stands for any type that is acceptable for an expression-statement to have (that is, a raw partial result), `Component` stands for any type that is acceptable for a partial or combined result to have, and `FinalResult` stands for any type that is acceptable to be ultimately returned by the transformed function.
+
+* `buildBlock(_ components: Component...) -> Component` is used to build combined results for statement blocks. It is required to be a static method in every result builder.
+
+* `buildOptional(_ component: Component?) -> Component` is used to handle a partial result that may or may not be available in a given execution. When a result builder provides `buildOptional(_:)`, the transformed function can include `if` statements without an `else`.
+
+* `buildEither(first: Component) -> Component` and `buildEither(second: Component) -> Component` are used to build partial results when a selection statement produces a different result from different paths. When a result builder provides these methods, the transformed function can include `if` statements with an `else` statement as well as `switch` statements.
+
+* `buildArray(_ components: [Component]) -> Component` is used to build a partial result given the partial results collected from all of the iterations of a loop. When a result builder provides `buildArray(_:)`, the transformed function can include `for..in` statements.
+
+* `buildExpression(_ expression: Expression) -> Component` is used to lift the results of expression-statements into the `Component` internal currency type. It is optional, but when provided it allows a result builder to distinguish `Expression` types from `Component` types or to provide contextual type information for statement-expressions.
+
+* `buildFinalResult(_ component: Component) -> FinalResult` is used to finalize the result produced by the outermost `buildBlock` call for top-level function bodies. It is optional, and allows a result builder to distinguish `Component` types from `FinalResult` types, e.g. if it wants builders to internally traffic in some type that it doesn't really want to expose to clients.
+
+* `buildLimitedAvailability(_ component: Component) -> Component` is used to transform the partial result produced by `buildBlock` in a limited-availability context (such as `if #available`) into one suitable for any context. It is optional, and is only needed by result builders that might carry type information from inside an `if #available` outside it.
+
+The set of requirements can be summarized by the following example result builder:
+
+```swift
+@resultBuilder
+struct ExampleResultBuilder {
+ /// The type of individual statement expressions in the transformed function,
+ /// which defaults to Component if buildExpression() is not provided.
+ typealias Expression = ...
+
+ /// The type of a partial result, which will be carried through all of the
+ /// build methods.
+ typealias Component = ...
+
+ /// The type of the final returned result, which defaults to Component if
+ /// buildFinalResult() is not provided.
+ typealias FinalResult = ...
+
+ /// Required by every result builder to build combined results from
+ /// statement blocks.
+ static func buildBlock(_ components: Component...) -> Component { ... }
+
+ /// If declared, provides contextual type information for statement
+ /// expressions to translate them into partial results.
+ static func buildExpression(_ expression: Expression) -> Component { ... }
+
+ /// Enables support for `if` statements that do not have an `else`.
+ static func buildOptional(_ component: Component?) -> Component { ... }
+
+ /// With buildEither(second:), enables support for 'if-else' and 'switch'
+ /// statements by folding conditional results into a single result.
+ static func buildEither(first component: Component) -> Component { ... }
+
+ /// With buildEither(first:), enables support for 'if-else' and 'switch'
+ /// statements by folding conditional results into a single result.
+ static func buildEither(second component: Component) -> Component { ... }
+
+ /// Enables support for 'for..in' loops by combining the
+ /// results of all iterations into a single result.
+ static func buildArray(_ components: [Component]) -> Component { ... }
+
+ /// If declared, this will be called on the partial result of an 'if
+ /// #available' block to allow the result builder to erase type
+ /// information.
+ static func buildLimitedAvailability(_ component: Component) -> Component { ... }
+
+ /// If declared, this will be called on the partial result from the outermost
+ /// block statement to produce the final returned result.
+ static func buildFinalResult(_ component: Component) -> FinalResult { ... }
+}
+```
+
+### The result builder transform
+
+The result builder transform is a recursive transformation operating on statement blocks and the individual statements within them.
+
+#### Statement blocks
+
+Within a statement block, the individual statements are separately transformed into sequences of statements which are then concatenated. Each such sequence may optionally produce a single *partial result*, which is an expression (typically a reference to a unique local variable defined as part of the transformation) which can be used later in the block.
+
+After the transformation has been applied to all the statements, a call to `buildBlock` is generated to form a *combined result*, with all the partial results as unlabelled arguments.
+
+If the statement block is the top-level body of the function being transformed, the final statement in the transformed block is a `return` with the combined result expression as its operand, wrapped in `buildFinalResult` if it was provided by the builder. Otherwise, the combined result is propagated outwards, typically by assigning it (possibly after a transformation) to a local variable in the enclosing block; the exact rule is specified in the section for the enclosing statement below.
+
+#### Declaration statements
+
+Local declarations are left alone by the transformation. This allows developers to factor out subexpressions freely to clarify their code, without affecting the result builder transformation.
+
+#### Expression statements
+
+An expression statement which does not perform an assignment is transformed as follows:
+
+* If the result builder type declares the `buildExpression` result-building method, the transformation calls it, passing the expression-statement as a single unlabeled argument. This call expression is hereafter used as the expression statement. This call is type-checked together with the statement-expression and may influence its type.
+
+* The statement-expression is used to initialize a unique variable of the statement-expression's result type, as if by `let v = `. This variable is treated as a partial result of the containing block. References to this variable are type-checked independently from it so that they do not affect the type of the expression.
+
+The ability to control how expressions are embedded into partial results is an important advantage for certain kinds of DSL, including our HTML example. In the original HTML example, we have an `HTML` protocol with a very small (and essentially fixed) number of implementing types. This would probably be more natural to represent in Swift as an `enum` rather than a `protocol`, but that would prevent a `String` from being written directly wherever an `HTML` was required, which would make complex `HTML` literals even more onerous to write in our original, pre-DSL solution:
+
+```swift
+return body([
+ division([
+ header1("Chapter 1. Loomings."),
+ paragraph([.text("Call me Ishmael. Some years ago")]),
+ paragraph([.text("There is now your insular city")])
+ ]),
+ division([
+ header1("Chapter 2. The Carpet-Bag."),
+ paragraph([.text("I stuffed a shirt or two")])
+ ])
+])
+```
+
+By using a DSL with `buildExpression`, however, we can use an `enum` for its natural representational, pattern-matching, and other advantages, then just add overloads to `buildExpression` to make it easier to build common cases within the DSL:
+
+```swift
+static func buildExpression(_ text: String) -> [HTML] {
+ return [.text(text)]
+}
+
+static func buildExpression(_ node: HTMLNode) -> [HTML] {
+ return [.node(node)]
+}
+
+static func buildExpression(_ value: HTML) -> [HTML] {
+ return [value]
+}
+```
+
+#### Assignments
+
+An expression statement which performs an assignment is treated in the same manner as all other expression statements, although it will always return `()`. A result builder could choose to handle `()`-returning expression statements specially by overloading `buildExpression`, e.g.,
+
+```swift
+static func buildExpression(_: ()) -> Component { ... }
+```
+
+#### Selection statements
+
+`if`/`else` and `switch` statements produce values conditionally depending on their cases. There are two basic transformation patterns which can be used, depending on the selection statement itself; we'll show examples of each, then explain the details of the transformation.
+
+Consider a simple "if" statement without an "else" block:
+
+```swift
+if i == 0 {
+ "0"
+}
+```
+
+The first transformation pattern for selection statements turns the case into its own optional partial result in the enclosing block. This is a simple transformation handling code that is optionally executed:
+
+```swift
+var vCase0: String?
+if i == 0 {
+ var thenVar = "0"
+ var thenBlock = BuilderType.buildBlock(thenVar)
+ vCase0 = BuilderType.buildOptional(.some(thenBlock))
+}
+```
+
+If `if` statement doesn't have a corresponding `else` block, like in our example, the result builder transform is going create one implicitly and inject a call to `buildOptional(.none)` as follows:
+
+```swift
+var vCase0: String?
+if i == 0 {
+ var thenVar = "0"
+ var thenBlock = BuilderType.buildBlock(thenVar)
+ vCase0 = BuilderType.buildOptional(.some(thenBlock))
+} else {
+ vCase0 = BuilderType.buildOptional(.none)
+}
+```
+
+The second transformation pattern produces a balanced binary tree of injections into a single partial result in the enclosing block. It supports `if`-`else` and `switch`. Consider the following code:
+
+```swift
+if i == 0 {
+ "0"
+} else if i == 1 {
+ "1"
+} else {
+ generateFibTree(i)
+}
+```
+
+Under this pattern, the example code becomes something like the following:
+
+```swift
+let vMerged: PartialResult
+if i == 0 {
+ var firstVar = "0"
+ var firstBlock = BuilderType.buildBlock(firstVar)
+ vMerged = BuilderType.buildEither(first: firstBlock)
+} else if i == 1 {
+ var secondVar = "1"
+ var secondBlock = BuilderType.buildBlock(secondVar)
+ vMerged = BuilderType.buildEither(second:
+ BuilderType.buildEither(first: secondBlock))
+} else {
+ var elseVar = generateFibTree(i)
+ var elseBlock = BuilderType.buildBlock(elseVar)
+ vMerged = BuilderType.buildEither(second:
+ BuilderType.buildEither(second: elseBlock))
+}
+```
+
+The detailed transformation of selection statements proceeds as follows. The child blocks of the statement are first analyzed to determine the number *N* of cases that can produce results and whether there are any cases that don't. The implementation is permitted to analyze multiple nesting levels of statements at once; e.g. if a `case` consists solely of an `if` chain, the cases of the `if` can be treated recursively as cases of the `switch` at the implementation's discretion. A missing `else` is a separate case for the purposes of this analysis, and will be handled by `buildOptional(_:)`.
+
+If *N* = 0, the statement is ignored by the transformation. Otherwise, an injection strategy is chosen:
+
+* If the result builder type declares the `buildEither(first:)` and `buildEither(second:)` result-building methods, a full binary tree with *N* leaves (the *injection tree*) is chosen, and each result-producing case is uniquely assigned a leaf in it; these decisions are implementation-defined. A unique variable `vMerged` of fresh type is declared before the statement.
+
+* Otherwise, unique variables `vCase` are declared before the statement for each result-producing case.
+
+The transformation then proceeds as follows:
+
+* In each result-producing case, the transformation is applied recursively. As the final statement in the case, the combined result is injected and assigned outwards:
+
+ * If the statement is not using an injection tree, the combined result is wrapped in `Optional.Some` and assigned to the appropriate `vCase`.
+
+ * Otherwise, the path from the root of the injection tree to the appropriate leaf is considered. An expression is formed by the following rules and then assigned to `vMerged`:
+
+ * For an empty path, the original combined result from the case.
+
+ * For a left branch through the tree, a call to the result-building method `buildEither(first:)` with the argument being the injection expression for the remainder of the path.
+
+ * For a right branch through the tree, the same but with `buildEither(second:)`.
+
+ * Finally, if there are any non-result-producing cases, the expression is wrapped in `Optional.some`.
+
+ For example, if the path to the case's leaf is `left`, `left`, `right`, and there are non-result-producing cases, and the original combined result is `E`, then the injection expression assigned to `vMerged` is
+
+ ```swift
+ Optional.some(
+ BuilderType.buildEither(first:
+ BuilderType.buildEither(first:
+ BuilderType.buildEither(second: E))))
+ ```
+
+ Note that all of the assignments to `vMerged` will be type-checked together, which should allow any free generic arguments in the result types of the injections to be unified.
+
+* After the statement, if there is an `if` that does not have a corresponding `else`, a new unique variable `v2` is initialized by calling the result-building method `buildOptional(_:)` with `v` as the argument, and `v2` is then a partial result of the surrounding block. Otherwise, there is a unique variable `vMerged`, and `vMerged` is a partial result of the surrounding block.
+
+#### Imperative control-flow statements
+
+`return` statements are ill-formed when they appear within a transformed function. However, note that the transformation is suppressed in closures that contain a `return` statement, so this rule is only applicable in `func`s and getters that explicitly provide the attribute.
+
+`break` and `continue` statements are ill-formed when they appear within a transformed function. These statements may be supported in some situations in the future, for example by treating all potentially-skipped partial results as optional.
+
+`guard` is provisionally ill-formed when it appears within a transformed function. Situations in which this statement may appear may be supported in the future, such as when the statement does not produce a partial result.
+
+#### Exception-handling statements
+
+`throw` statements are left alone by the transformation.
+
+`defer` statements are ill-formed when encountered in transformed functions.
+
+`do` statements with `catch` blocks are ill-formed when encountered in transformed functions.
+
+#### `do` statements
+
+`do` statements without `catch` blocks are effectively wrappers around a block statement, and are transformed accordingly:
+
+* A unique variable `v` is declared immediately prior to the `do`.
+
+* The transformation is applied recursively to the child statement block.
+
+* The combined result is assigned to `v` as the final statement in the child block, and `v` becomes a partial result of the containing block.
+
+#### `for`..`in` loops
+
+`for`...`in` statements execute each of the iterations of the loop, collecting the partial results from all iterations into an array. That array is then passed into `buildArray`. Specifically:
+
+* A unique variable `v` is declared immediately prior to the `for`.
+* A unique variable `vArray` is declared immediately prior to the `for`, is given `Array` type (with as-yet-undetermined element type), and is initialized to `[]`.
+* The transformation is applied recursively to the body of the `for`..`in` loop, except that the partial result produced by the body is appended to the array via a call to `vArray.append`.
+* The result of calling `buildArray(vArray)` is assigned to `v`, and `v` becomes a partial result of the containing block.
+
+If no `buildArray` is provided, `for`..`in` loops are not supported in the body.
+
+### Compiler Diagnostic Directives
+
+`#warning` and `#error` have no run-time impact and are left unchanged by the result builder transformation.
+
+### Availability
+
+Statements that introduce limited availability contexts, such as `if #available(...)`, allow the use of newer APIs while still making the code backward-deployable to older versions of the libraries. A result builder that carries complete type information (such as SwiftUI's [`ViewBuilder`](https://developer.apple.com/documentation/swiftui/viewbuilder)) may need to "erase" type information from a limited availability context using `buildLimitedAvailability`. Here is a SwiftUI example borrowed from [Paul Hudson](https://www.hackingwithswift.com/quick-start/swiftui/how-to-lazy-load-views-using-lazyvstack-and-lazyhstack):
+
+```swift
+@available(macOS 10.15, iOS 13.0, *)
+struct ContentView: View {
+ var body: some View {
+ ScrollView {
+ if #available(macOS 11.0, iOS 14.0, *) {
+ LazyVStack {
+ ForEach(1...1000, id: \.self) { value in
+ Text("Row \(value)")
+ }
+ }
+ } else {
+ VStack {
+ ForEach(1...1000, id: \.self) { value in
+ Text("Row \(value)")
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+`LazyVStack` was introduced in macOS 11/iOS 14.0, but this view is also available on macOS 10.15/iOS 13.0, so it uses `if #available`. SwiftUI carries complete type information throughout the view builder closure, including conditional branches:
+
+```swift
+static func buildEither(first: TrueContent) -> _ConditionalContent
+```
+
+This means that the type of the `ScrollView` will refer to `LazyVStack`, even on macOS 10.15/iOS 13.0, which results in a compilation error. `buildLimitedAvailability` provides a way for the result builder to "erase" type information it would normally keep, specifically in these situations:
+
+```swift
+static func buildLimitedAvailability(_ content: Content) -> AnyView { .init(content) }
+```
+
+Consider a cut-down example focusing on the `if #available`:
+
+```swift
+if #available(macOS 11.0, iOS 14.0, *) {
+ LazyVStack { }
+} else {
+ VStack { }
+}
+```
+
+This will be transformed as:
+
+```swift
+let vMerged: *inferred type*
+if #available(macOS 11.0, iOS 14.0, *) {
+ let v0 = LazyVStack { }
+ let v1 = ViewBuilder.buildBlock(v0)
+ let v2 = ViewBuilder.buildLimitedAvailability(v1)
+ vMerged = ViewBuilder.buildEither(first: v2)
+} else {
+ let v3 = VStack { }
+ let v4 = ViewBuilder.buildBlock(v3)
+ vMerged = ViewBuilder.buildEither(second: v4)
+}
+```
+
+### **Example**
+
+Let's return to our earlier example and work out how to define a result-builder DSL for it. First, we need to define a basic result builder type:
+
+```swift
+@resultBuilder
+struct HTMLBuilder {
+ // We'll use these typealiases to make the lifting rules clearer in this example.
+ // Result builders don't really require these to be specific types that can
+ // be named this way! For example, Expression could be "either a String or an
+ // HTMLNode", and we could just overload buildExpression to accept either.
+ // Similarly, Component could be "any Collection of HTML", and we'd just have
+ // to make buildBlock et al generic functions to support that. But we'll keep
+ // it simple so that we can write these typealiases.
+
+ // Expression-statements in the DSL should always produce an HTML value.
+ typealias Expression = HTML
+
+ // "Internally" to the DSL, we'll just build up flattened arrays of HTML
+ // values, immediately flattening any optionality or nested array structure.
+ typealias Component = [HTML]
+
+ // Given an expression result, "lift" it into a Component.
+ //
+ // If Component were "any Collection of HTML", we could have this return
+ // CollectionOfOne to avoid an array allocation.
+ static func buildExpression(_ expression: Expression) -> Component {
+ return [expression]
+ }
+
+ // Build a combined result from a list of partial results by concatenating.
+ //
+ // If Component were "any Collection of HTML", we could avoid some unnecessary
+ // reallocation work here by just calling joined().
+ static func buildBlock(_ children: Component...) -> Component {
+ return children.flatMap { $0 }
+ }
+
+ // We can provide this overload as a micro-optimization for the common case
+ // where there's only one partial result in a block. This shows the flexibility
+ // of using an ad-hoc builder pattern.
+ static func buildBlock(_ component: Component) -> Component {
+ return component
+ }
+
+ // Handle optionality by turning nil into the empty list.
+ static func buildOptional(_ children: Component?) -> Component {
+ return children ?? []
+ }
+
+ // Handle optionally-executed blocks.
+ static func buildEither(first child: Component) -> Component {
+ return child
+ }
+
+ // Handle optionally-executed blocks.
+ static func buildEither(second child: Component) -> Component {
+ return child
+ }
+}
+```
+
+Next, we need to adjust our convenience functions to use it:
+
+```swift
+func body(@HTMLBuilder makeChildren: () -> [HTML]) -> HTMLNode {
+ return HTMLNode(tag: "body", attributes: [:], children: makeChildren())
+}
+func division(@HTMLBuilder makeChildren: () -> [HTML]) -> HTMLNode { ... }
+func paragraph(@HTMLBuilder makeChildren: () -> [HTML]) -> HTMLNode { ... }
+```
+
+Now we can go back to the example code and see how the transformation acts on a small part of it:
+
+```swift
+division {
+ if useChapterTitles {
+ header1(chapter + "1. Loomings.")
+ }
+ paragraph {
+ "Call me Ishmael. Some years ago"
+ }
+ paragraph {
+ "There is now your insular city"
+ }
+}
+```
+
+The transformation proceeds one-by-one through the top-level statements of the closure body passed to `division`.
+
+For the `if` statement, we see that there are two cases: the “then” case and the implicit “else” case. The first produces a result (because it has a non-assignment expression-statement), the second does not. We apply the recursive transformation to the “then” case:
+
+```swift
+ if useChapterTitles {
+ let v0: [HTML] = HTMLBuilder.buildExpression(header1(chapter + "1. Loomings."))
+ // combined result is HTMLBuilder.buildBlock(v0)
+ }
+```
+
+We're not using an injection tree because this is a single `if` without an `else`:
+
+```swift
+ var v0_opt: [HTML]?
+ if useChapterTitles {
+ let v0: [HTML] = HTMLBuilder.buildExpression(header1(chapter + "1. Loomings."))
+ v0_opt = v0
+ }
+ let v0_result = HTMLBuilder.buildOptional(v0_opt)
+ // partial result is v0_result
+```
+
+The two calls to `paragraph` happen to involve arguments which are also transformed blocks; we'll leave those alone for now, but
+suffice it to say that they'll also get transformed in time when the type-checker gets around to checking those calls. These are just non-assignment expression-statements, so we just lift them into the `Component` type:
+
+```swift
+division {
+ var v0_opt: [HTML]?
+ if useChapterTitles {
+ let v0: [HTML] = HTMLBuilder.buildExpression(header1(chapter + "1. Loomings."))
+ v0_opt = v0
+ }
+ let v0_result = HTMLBuilder.buildOptional(v0_opt)
+
+ let v1 = HTMLBuilder.buildExpression(paragraph {
+ "Call me Ishmael. Some years ago"
+ })
+
+ let v2 = HTMLBuilder.buildExpression(paragraph {
+ "There is now your insular city"
+ })
+
+ // partial results are v0_result, v1, v2
+}
+```
+
+Finally, we finish this block with a call to `buildBlock`. This is the top-level body of the function, but the result builder type doesn't declare `buildFinalResult`, that result is returned directly:
+
+```swift
+division {
+ var v0_opt: [HTML]?
+ if useChapterTitles {
+ let v0: [HTML] = HTMLBuilder.buildExpression(header1(chapter + "1. Loomings."))
+ v0_opt = v0
+ }
+ let v0_result = HTMLBuilder.buildOptional(v0_opt)
+
+ let v1 = HTMLBuilder.buildExpression(paragraph {
+ "Call me Ishmael. Some years ago"
+ })
+
+ let v2 = HTMLBuilder.buildExpression(paragraph {
+ "There is now your insular city"
+ })
+
+ return HTMLBuilder.buildBlock(v0_result, v1, v2)
+}
+```
+
+This closure has now been completely transformed (except for the nested closures passed to `paragraph`).
+
+## Type inference
+
+### Result builder bodies
+Type inference in result builder bodies follows from the syntactic effects of the result builder transformation.
+For example, when applying the result builder to the following closure:
+
+```swift
+{
+ 42
+ 3.14159
+}
+```
+
+the result builder transformation produces
+
+```swift
+let v1 = 42
+let v2 = 3.14159
+return Builder.buildBlock(v1, v2)
+```
+
+The types for `v1` and `v2` are determined independently by the normal type inference rules to `Int` and `Double`,
+respectively, then `buildBlock` can operate on both types to produce the final result of the closure.
+However, the type of `buildBlock` cannot have any effect on how the types of `v1` and `v2` are
+computed. For example, if the builder contained a `buildBlock` like the following:
+
+```swift
+func buildBlock(_ a: T, _ b: T) -> T { ... }
+```
+
+Then the call to `buildBlock(v1, v2)` will fail because `Int` and `Double` have different types, even though the integer literal `42` could have been treated as a `Double` if type inference were permitted to propagate information "backward" to affect `v1`.
+
+Note that the first implementation of result builders in Swift 5.1 used a different syntactic transform that *did* allow such backward propagation, e.g.,
+
+```swift
+return Builder.buildBlock(42, 3.14159) // not proposed; example only
+```
+
+in which case the `42` would be treated as a `Double`. There are several reasons why allowing such "backward" propagation of type information is undesirable for result builders:
+* The type inference model would be different from normal closures or function bodies, which is a divergence that makes the mental model more complicated
+* Type checker performance with moderate-to-large result builder bodies was unacceptable, because backward propagation introduced exponential behavior. The implementation of [one-way constraints](https://github.com/apple/swift/pull/26661) for result builders (which introduced the current behavior) resolved most reported "expression too complex to be solved in a reasonable time" issues with SwiftUI code.
+
+### Inferring result builders from protocol requirements
+
+Most result builder transformations are applied implicitly, without the client of the API writing the name of the result builder. For example, given the following API:
+
+```swift
+func paragraph(@HTMLBuilder makeChildren: () -> [HTML]) -> HTMLNode { ... }
+```
+
+The result builder `HTMLBuilder` is applied at each call site, implicitly, when the closure argument is matched to the parameter that has a result builder attribute:
+
+```swift
+paragraph {
+ "Call me Ishmael. Some years ago"
+}
+```
+
+Most function declarations are standalone, so only the explicit result builder annotation can enable the transformation. However, result builder DSLs like SwiftUI tend to have a central protocol to which many different types conform. A typical SwiftUI view might look something like this:
+
+```swift
+struct ContentView: View {
+ @ViewBuilder var body: some View {
+ Image(named: "swift")
+ Text("Hello, Swift!")
+ }
+}
+```
+
+Nearly every `body` for a SwiftUI view can use `@ViewBuilder`, because `body` defines a `View`, and those are best built with a `ViewBuilder`. To eliminate the boilerplate from writing `@ViewBuilder` on each, one can annotate `body` with `@ViewBuilder` in the `View` protocol itself:
+
+```swift
+protocol View {
+ associatedtype Body: View
+ @ViewBuilder var body: Body { get }
+}
+```
+
+When a `View`-conforming type defines its `body`, the `@ViewBuilder` attribute is inferred from the protocol requirement it satisfies, implicitly applying the result builder transform. This inference occurs unless:
+* The function or property already has a result builder attribute explicitly written on it, or
+* The body of the function or property getter contains an explicit `return` statement.
+
+### Implicit memberwise initializer
+
+Result builders are designed with composition in mind, and it is common to have a number of small structures that use result builders to describe their child content. For example, a custom VStack in SwiftUI might look like this:
+
+```swift
+struct CustomVStack: View {
+ let content: () -> Content
+
+ var body: some View {
+ VStack {
+ // custom stuff here
+ content()
+ }
+ }
+}
+```
+
+However, this custom VStack doesn't work with result builder syntax without writing an initializer to introduce the `@ViewBuilder` attribute:
+
+```swift
+init(@ViewBuilder content: @escaping () -> Content) {
+ self.content = content
+}
+```
+
+A result builder attribute can be placed on a stored property. This introduces the result builder attribute on the corresponding parameter of the implicit memberwise initializer. In other words, changing the `CustomVStack` definition to the following:
+
+```swift
+struct CustomVStack: View {
+ @ViewBuilder let content: () -> Content
+
+ var body: some View {
+ VStack {
+ // custom stuff here
+ content()
+ }
+ }
+}
+```
+
+implicitly produces the memberwise initializer shown above.
+
+A result builder attribute can also be placed on a stored property whose type does not [structurally resemble function type](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0286-forward-scan-trailing-closures.md#structural-resemblance-to-a-function-type). In this case, the implicit memberwise initializer will have a corresponding function parameter that is a result-builder-attributed closure returning the property's type, and the body of the initializer will call the function. For example, given:
+
+```swift
+struct CustomHStack: View {
+ @ViewBuilder let content: Content
+
+ var body: some View {
+ HStack {
+ // custom stuff here
+ content
+ }
+ }
+}
+```
+
+the implicit memberwise initializer would have the following definition:
+
+```swift
+init(@ViewBuilder content: () -> Content) {
+ self.content = content()
+}
+```
+
+This idea was reported as [SR-13188](https://bugs.swift.org/browse/SR-13188), and the examples are pulled from there.
+
+## Source compatibility
+
+Result builders are an additive feature which should not affect existing source code.
+
+Because some decisions with result builders are implementation-defined, e.g. the structure of the injection tree for `switch` statements, it is possible that certain DSLs will observe differences in behavior across future compiler versions if they are written to observe such differences.
+
+## Effect on ABI stability and API resilience
+
+Result builders are based on compile-time code generation and do not require support from the language runtime or standard library.
+
+Because result builders are essentially a kind of macro system, where the details of expansion are basically an aspect of the current implementation rather than necessarily a stable interface, library authors are encouraged to make as much as possible inlinable and, if possible, non-ABI.
+
+## Future Directions
+
+There are a number of future directions that could be layered on top of this proposal without compromising its basic design. Several of them are covered here.
+
+### "Simple" result builder protocol
+
+On the Swift forums, @anreitersimon [demonstrated](https://forums.swift.org/t/pitch-2-function-builders/39410/6) the ability to use protocols to make it easier to define new result builders that support all of the syntax, and for which all expressions have the same type. Their example (slightly tuned) follows. The basic idea is to form a tree describing the result:
+
+```swift
+enum Either {
+ case first(T)
+ case second(U)
+}
+
+indirect enum ResultBuilderTerm {
+ case expression(Expression)
+ case block([ResultBuilderTerm])
+ case either(Either)
+ case optional(ResultBuilderTerm?)
+}
+```
+
+and then define a `ResultBuilder` protocol with only a single requirement, `buildFinalResult`, to take all of the values and form the final result:
+
+```swift
+protocol ResultBuilder {
+ associatedtype Expression
+ typealias Component = ResultBuilderTerm
+ associatedtype FinalResult
+
+ static func buildFinalResult(_ component: Component) -> FinalResult
+}
+```
+
+All of the other `build` methods---to enable `if`, `switch`, and so on---are implemented in an extension of `ResultBuilder`:
+
+```swift
+extension ResultBuilder {
+ static func buildExpression(_ expression: Expression) -> Component { .expression(expression) }
+ static func buildBlock(_ components: Component...) -> Component { .block(components) }
+ static func buildOptional(_ component: Component?) -> Component { .optional(component) }
+ static func buildArray(_ components: [Component]) -> Component { .block(components) }
+ static func buildLimitedAvailability(_ component: Component) -> Component { component }
+}
+```
+
+It then becomes possible to define new version builders with only a small amount of code, e.g., here is a builder that flattens the result term into an array:
+
+```swift
+@resultBuilder
+enum ArrayBuilder: ResultBuilder {
+ typealias Expression = E
+ typealias FinalResult = [E]
+
+ static func buildFinalResult(_ component: Component) -> FinalResult {
+ switch component {
+ case .expression(let e): return [e]
+ case .block(let children): return children.flatMap(buildFinalResult)
+ case .either(.first(let child)): return buildFinalResult(child)
+ case .either(.second(let child)): return buildFinalResult(child)
+ case .optional(let child?): return buildFinalResult(child)
+ case .optional(nil): return []
+ }
+ }
+}
+```
+
+With some more experience, a facility like this could become part of the standard library.
+
+### Stateful result builders
+All of the `build*` methods for a result builder type are defined to be `static`, and no instances of the result builder type are created by the result builder transform. However, the transform could create an instance of the result builder type at the beginning of the transformed function, then call `build*` instance methods on it. For example, this code adapted from [Constantino Tsarouhas](https://forums.swift.org/t/pitch-2-function-builders/39410/67)):
+
+```swift
+struct Heading : Element {
+ init(@ElementBuilder(containerStyle: .inline) content: () -> Content) { … }
+}
+
+Heading {
+ Text("Loomings")
+ Text("Call me Ishmael. Some years ago")
+}
+```
+
+would be translated as:
+
+```swift
+Heading {
+ var builder = ElementBuilder(containerStyle: .inline)
+ let v0 = builder.buildExpression(Text("Loomings"))
+ let v1 = builder.buildExpression(Text("Call me Ishmael. Some years ago"))
+ let v2 = builder.buildBlock(v0, v1)
+ return builder.buildFinalResult(v2)
+}
+```
+
+The introduction of stateful result builders would be a pure extension. However, the same effect can be achieved by the "simple result builder protocol" described above, so it is not clear that this facility belongs in the language.
+
+### Transforming declarations
+
+Result builders leave all declaration statements unmodified. However, some DSLs might want to incorporate declarations, notifying the builder of such declarations so it can incorporate them. Here's an abstracted example based on one [provided by Konrad Malawski](https://forums.swift.org/t/function-builders-and-including-let-declarations-in-built-result/37184):
+
+```swift
+Definition {
+ Thing {
+ // "import" the Def people, in order to be able to use it in this Thing
+ // there may be many Defs, but this Thing only uses people
+ let people = Defs.people // <1>
+ let other = Def.otherThings // <2>
+
+ show {
+ people.name // <1>
+ people.surname // <1>
+ other.information // <2>
+ }
+ filter {
+ equals(people.age, 42)
+ }
+ }
+}
+```
+
+The builder could be informed of each `let` declaration, allowing it to produce a partial result, e.g., the innermost `Thing` could be transformed to:
+
+```swift
+let people = Defs.people
+let v0 = ThingBuilder.buildDeclaration(people)
+let other = Def.otherThings
+let v1 = ThingBuilder.buildDeclaration(other)
+
+let v2 =
+let v3 =
+let v4 = ThingBuilder.buildBlock(v0, v1, v2, v3)
+```
+
+Such DSLs would not change the way declarations are type checked, but would have the option to produce partial results for them, which could further eliminate boilerplate. On the other hand, without this feature one can freely use `let` to pull out subexpressions and partial computations without changing the code. For example, today one expects to be able to refactor
+
+```swift
+a.doSomething().doSomethingElse()
+```
+
+into
+
+```swift
+let b = a.doSomething()
+b.doSomethingElse()
+```
+
+without changing semantics. That would no longer be the case for result builders that opt in to this feature by providing `buildDeclaration`.
+
+### Virtualized Abstract Syntax Trees (ASTs)
+
+The result builder model executes the transformed function directly, collecting the partial results that get passed into the builder. Some DSLs might prefer to "virtualize" the structure of the transformed function, such that the DSL can determine how the evaluation happens. A simple form of this can be achieved by using escaping autoclosures in `buildExpression:`:
+
+```swift
+typealias DelayedValue = () -> Any
+
+static func buildExpression(_ value: @autoclosure @escaping () -> Any) -> DelayedValue {
+ return value
+}
+```
+
+Here, the partial results provided to other build methods (e.g., `buildBlock`) will be functions that produce the value. The DSL is free to call those functions whenever it wants to produce the values.
+
+However, virtualizing any kind of control flow would require a new kind of build method that describes more of the structure of the AST. For example, consider a `for..in` loop:
+
+```swift
+for person in employees {
+ "Hello, \(person.preferredName)"
+}
+```
+
+Result builders currently will execute all iterations of the loop. Virtualizing the execution means passing along the means to execute the loop to the result builder, e.g., via a `buildVirtualFor` operation:
+
+```swift
+Builder.buildVirtualFor(employees, { person in
+ let v0 = Builder.buildExpression("Hello, \(person.preferredName)")
+ return Builder.buildBlock(v0)
+}
+```
+
+The builder's `buildVirtualFor` would have a signature such as:
+
+```swift
+static func buildVirtualFor(_ sequence: S, @escaping (S.Element) -> T) -> ForEach { ... }
+```
+
+Such a facility could be used to map the language's `for..in` syntax to a lazily-evaluated construct like SwiftUI's [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach). Similar builder methods would need to be developed for each supported syntax, e.g., `if` statements where the condition and then/else blocks are provided via closures.
+
+Virtualized ASTs would be a powerful extension to result builders. However, they will require an additional set of builder methods that match more closely with the syntax of the function being transformed.
+
+## Alternatives considered
+
+### Additional control-flow statements
+The set of statements that are permitted within a transformed function are intentionally limited to those that are "strictly structural", and could reasonably be thought of as being part of a single, functional expression, aggregating values but without complicated control flow. However, one could go beyond this model to accept additional statements in a transformed function:
+
+* Local control flow statements that aren't “strictly structural”, like `break`, `continue`, and `do/catch`, could be handled by treating subsequent partial results as optional, as if they appeared within an `if`.
+* Iteration statements other than `for`..`in` (i.e., `while` and `repeat`..`while`) could be supported via `buildArray`.
+
+Support for additional control-flow statements would weaken the declarative feel of result builders, and makes the "tree" structure of the DSL harder to reason about.
+
+It has been suggested that there could be two "forms" of result builders, one that matches the design in this proposal and a second, "simpler" one that handles the full breadth of the statement grammar (including all loops, `break`, `continue`, and so on) but sees only the partial results (e.g., via `buildExpression`) and not the structure (`buildBlock`, `buildEither(first:)`, etc. would not get called). The "simple result builder protocol" described above illustrates how one can get the second part of this--defining a simple result builder that receives all of the values without the structure--by building on top of this proposal. However, we should not have two forms of result builders in the language itself, with different capabilities, because it leads to confusion. If result builders gain support for additional control-flow statements (as a general feature), that should be reflected in the "simple result builder protocol" to extend the feature set for result builders that don't want the structure.
+
+### Builder-scoped name lookup
+It is common for DSLs to want to introduce shorthands which might be unreasonable to introduce into the global scope. For example, `p` might be a reasonable name in the context of our `HTMLBuilder` DSL (rather than `paragraph`), but actually introducing a global function named `p` just for DSL use is quite unfortunate. Contextual lookups like `.p` will generally not work at the top level in DSLs because they will be interpreted as continuations of the previous statement. One could imagine having some way for the DSL to affect lexical lookup within transformed functions so that, e.g., within the transformed function one could use short names like `p`, `div`, and `h1`:
+
+```swift
+return body {
+ let chapter = spellOutChapter ? "Chapter " : ""
+ div {
+ if useChapterTitles {
+ h1(chapter + "1. Loomings.")
+ }
+ p {
+ "Call me Ishmael. Some years ago"
+ }
+ p {
+ "There is now your insular city"
+ }
+ }
+}
+```
+
+which are defined in the result builder type itself, e.g.,
+
+```swift
+extension HTMLBuilder {
+ static func body(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func div(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func p(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func h1(_ text: String) -> HTMLNode { ... }
+}
+```
+
+Name lookup that doesn't find the names `p`, `div`, or `h1` within the closure would look into the result builder being used to transform the closure before continuing lexical name lookup.
+
+Note that one can simulate this kind of effect by following the common pattern set out by SwiftUI, where the transformed function is usually within a type that conforms to some common protocol. For example, if we were to always say that HTML documents are types that conform to an `HTMLDocument` protocol, like this:
+
+```swift
+protocol HTMLDocument {
+ @HTMLBuilder var body: HTML { get }
+}
+
+struct MobyDick: HTMLDocument {
+ var body: HTML {
+ let chapter = spellOutChapter ? "Chapter " : ""
+ div {
+ if useChapterTitles {
+ h1(chapter + "1. Loomings.")
+ }
+ p {
+ "Call me Ishmael. Some years ago"
+ }
+ p {
+ "There is now your insular city"
+ }
+ }
+ }
+}
+```
+
+Here, one can put the shorthand names (or, indeed, everything defined for the DSL) into an extension of the protocol:
+
+```swift
+extension HTMLDocument {
+ static func body(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func div(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func p(@HTMLBuilder _ children: () -> [HTML]) -> HTMLNode { ... }
+ static func h1(_ text: String) -> HTMLNode { ... }
+}
+```
+
+### Dropping Void/Never values
+
+During the first review, it was [suggested](https://forums.swift.org/t/se-0289-function-builders/39889/33) that a `Void` or `Never`-returning `buildExpression` method should cause the corresponding value to be dropped from the result builder itself. For example, the following result builder collects string values and puts them into a comma-separated string:
+
+```swift
+@resultBuilder
+struct StringConcatenator {
+ static func buildExpression(_ string: String) -> String { string }
+
+ static func buildBlock(_ strings: String...) -> String {
+ strings.joined(separator: ", ")
+ }
+}
+```
+
+However, it will reject any statements that don't produce a `String`. What if the builder wanted to allow other statements, but without collecting the values? One could re-work the builder like this:
+
+```swift
+@resultBuilder
+struct StringConcatenator {
+ static func buildExpression(_ string: String) -> String? { string }
+ static func buildExpression(_: T) -> String? { nil }
+
+ static func buildBlock(_ strings: String?...) -> String {
+ strings.compactMap({$0}).joined(separator: ", ")
+ }
+}
+```
+
+However, it's a non-obvious change to the result builder. The suggestion is to allow the original builder to be extended with a `Void`-producing `buildExpression`, e.g.,
+
+```swift
+static func buildExpression(_: T) { }
+```
+
+and have any `Void`-producing partial results be dropped. For example, applying
+the result builder to this closure:
+
+```swift
+func applyStringConcatenator(@StringConcatenator _: () -> String) { ... }
+
+applyStringConcatenator {
+ "hello"
+ 3.14159
+ "world"
+}
+```
+
+would produce "hello, world". While this is perhaps easier for the the author of the result builder, it makes the translation of the closure much less predictable. The basic translation of that closure would be to:
+
+```swift
+applyStringConcatenator {
+ let a = StringConcatenator.buildExpression("hello")
+ let b = StringConcatenator.buildExpression(3.14159)
+ let c = StringConcatenator.buildExpression("world")
+ return StringConcatenator.buildBlock(a, b, c)
+}
+```
+
+With this proposal, the formation of the `buildBlock` call would depend on the type inference for the partial result variables `a`, `b`, and `c`. In other words, because `b` will be inferred to type `Void`, the actual `buildBlock` call would end up being `StringConcatenator.buildBlock(a, c)`. This complication to the mental model outweighs the benefits to authors of result builders, because this feature isn't adding any expressive power--it's a shortcut to make it more convenient to address this case.
diff --git a/proposals/0290-negative-availability.md b/proposals/0290-negative-availability.md
new file mode 100644
index 0000000000..2d43fdcce4
--- /dev/null
+++ b/proposals/0290-negative-availability.md
@@ -0,0 +1,253 @@
+# Unavailability Condition
+
+* Proposal: [SE-0290](0290-negative-availability.md)
+* Author: [Bruno Rocha](https://github.com/rockbruno)
+* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
+* Implementation: [apple/swift#33932](https://github.com/apple/swift/pull/33932)
+* Status: **Implemented (Swift 5.6)**
+* Previous revision: [1](https://github.com/swiftlang/swift-evolution/blob/066545c1cc9ff2b87ce233e0f8936f8d53724bdb/proposals/0290-negative-availability.md)
+* Decision Notes: [Review #1](https://forums.swift.org/t/se-0290-unavailability-condition/41873/34), [Review #2](https://forums.swift.org/t/se-290-second-review-unavailability-condition/43544/59)
+
+## Introduction
+
+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.
+
+Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/support-negative-availability-literals/39946)
+
+## Motivation
+
+Checking whether a specific platform/symbol is **not** available is necessary when the changes made to an API are so extreme that you cannot represent it in a single if/else statement. The most common example is how building an iOS app's main `UIWindow` changed with the introduction of `SceneDelegates`. While a basic iOS 12 `AppDelegate` app sets up its window when the app finishes launching, apps that support `SceneDelegates` should instead do it *later* in the app's lifecycle -- more specifically, when the AppDelegate connects the app's main `UIScene`. Since this happens outside the usual `didFinishLaunching` flow, this extreme difference in behavior cannot be conveyed by a simple if/else availability check. Instead, the `AppDelegate` will require a *negative* platform check that makes it sure it only sets up the window if the user is **not** running iOS 13:
+
+```swift
+// if NOT in iOS 13, load the window.
+// Post iOS 13 the window is loaded later in the lifecycle, in the SceneDelegate.
+if #available(iOS 13, *) {
+
+} else {
+ loadMainWindow()
+}
+```
+
+### Readability
+
+As you might notice, the current way to achieve negative availability checks is by working around the current `#available` keyword. Because the availability condition is not parsed as an expression, it cannot be negated with regular boolean operations (`!`/`== false`). The way instead is to make use of the `else` clause, but as unavailability checks are not interested at all in the positive portion of the check, doing so will leave behind an empty `if` branch. For context, this problem does not exist in Objective-C as `if (@available(iOS 13.0, *) == NO)` is a valid expression.
+
+With the exception of this very specific case, an empty statement is a sure sign that there's something wrong in the developer's code, and it is likely that every unavailability check like this had to include a comment to indicate that it was done on purpose due to the compiler's limitations. In some cases, it might even be necessary to add an exclusion rule to the project's linters as most would assume that this is a mistake and incorrectly suggest that it can be fixed by negating the statement.
+
+This workaround has a clear negative impact on the readability of the unavailability check, as no one would expect an empty `if` statement to not be a coding mistake. Most developers will attempt to hide the problem by putting the positive portion in a single line:
+
+```swift
+// if NOT in iOS 13, load the window.
+// Post iOS 13 the window is loaded later in the lifecycle, in the SceneDelegate.
+if #available(iOS 13, *) {} else {
+ loadMainWindow()
+}
+```
+
+Unfortunately, this makes it easy to mistake it for a regular availability check. If the comment isn't clear that the statement is wrong on purpose, problems involving this check could easily land unnoticed in code-reviews. A less noisy way would be to put it under a `guard`:
+
+```swift
+guard #available(iOS 13, *) else {
+ loadMainWindow()
+ return
+}
+// no-op
+```
+
+However, this goes against the code style recommendations involving the usage of `guard`. The guarded part should be the happy path, which is not the case when doing unavailability checks. As shown, it's currently impossible to write an unavailability check that properly fits a developer's engineering expectations and Swift's general style guide.
+
+Currently, any iOS application that supports UIScenes will face this issue and have to write this workaround. To describe it in a generic way, this issue will be encountered when dealing with any API addition or change that requires more than one availability condition to be implemented.
+
+### Usage of deprecated APIs
+
+A negative availability condition might also be necessary in cases where an API is marked as deprecated (and documented as non-functional) in newer OS versions.
+
+An example is the deprecation of the [`isAdvertisingTrackingEnabled`](https://developer.apple.com/documentation/adsupport/asidentifiermanager/1614148-isadvertisingtrackingenabled) property. Apps supporting iOS 14 must now use the new App Tracking Transparency framework for user tracking purposes, which involves displaying a permission alert for the user that explains why they are going to be tracked. A developer might determine that this large change in functionality might warrant a complete refactor of this feature, or simply conclude that the negative UX of displaying a new alert is not worth it and that they should remove this feature entirely. In any case however, the property still works when used with older iOS versions:
+
+```swift
+// If NOT on iOS 14, track this action.
+// Post iOS 14, we must ask for permission to do this.
+// The UX impact is not worth it. Let's not do this at all.
+if #available(iOS 14.0) {
+
+} else {
+ oldIos13TrackingLogic(isEnabled: ASIdentifierManager.shared().isAdvertisingTrackingEnabled)
+}
+```
+
+In this specific case, a company that wants to adopt the new privacy practices will require unavailability checks to prevent breaking old versions of the app. In general, this will be the case when dealing with any API that is now deprecated.
+
+### Code Structure
+
+Besides cases where having an unavailability check is mandatory, supporting them would give developers more options when structuring their code in cases where they are not mandatory. By not being forced to consider the availability of something as the happy path, developers would have more choices when considering how to architect and abstract certain pieces of code.
+
+## Proposed solution
+
+Given that Objective-C is capable of negating availability checks, we believe that this not being supported in Swift was simply an oversight. We would like to propose this feature back to Swift in the shape of a new `#unavailable` condition:
+
+```swift
+if #unavailable(iOS 13, *) {
+ loadMainWindow()
+}
+```
+
+As dictated by the name, `#unavailable` is the reverse version of `#available`. Having a proper unavailability check will eliminate the need to use the current workaround and makes it clear to the reader that the statement is checking for the *lack* of a specific version, eliminating the need to provide a comment explaining what that piece of code is trying to achieve.
+
+Like with `#available`, `#unavailable` has the capacity to increase the symbol availability of a scope. As opposed to `#available`, the availability is increased at the `else` clause.
+
+```swift
+if #unavailable(iOS 13, *) {
+ // Symbol Availability: Default (deployment target)
+} else {
+ // Symbol Availability: iOS 13
+}
+```
+
+## Detailed design
+
+As the compiler is already able to calculate the symbol availability for both the positive and negative flows of the check, implementing `#unavailable` is simply a matter of introducing a new keyword that reverses them. This allows `#unavailable` to be internally implemented as a simple boolean that flips `#available's` functionality.
+
+Implementation: [apple/swift#33932](https://github.com/apple/swift/pull/33932)
+
+### Preventing impossible conditions
+
+The ability to use several availability checks in a single statement allows positive and negative availability checks to be mixed. This will lead to an ambiguous symbol availability:
+
+```swift
+// User running something between iOS 9 and 12
+if #available(iOS 9.0, *), #unavailable(iOS 13.0, *) {
+ // Symbol Availability: iOS 9.0
+} else {
+ // Symbol Availability: ???
+}
+```
+
+The availability of the else block cannot be determined because it depends on which of the two conditions is false. To prevent this from happening, the compiler will emit a diagnostic whenever this happens.
+
+```swift
+if #available(iOS 9.0, *), #unavailable(iOS 13.0, *)
+// error: #available and #unavailable cannot be in the same statement
+```
+
+Technically we could support this by *not* improving the symbol availability of a scope if it's ambiguous, but as there are currently no legitimate cases where one would have to mix availability with unavailability, the author believes the work necessary to support this and its edge cases is not worth it at the time this proposal was written. However, you can still use them as separate statements.
+
+```swift
+if #available(iOS 9.0, *) {
+ // Symbol Availability: iOS 9.0
+ if #unavailable(iOS 13.0, *) {
+ // Symbol Availability: iOS 9.0
+ } else {
+ // Symbol Availability: iOS 13.0
+ }
+} else {
+ // Symbol Availability: Default (deployment target)
+}
+```
+
+As they are separate statements, there's no ambiguity.
+
+### Multiple Elses
+
+In the case of multiple else flows, the compiler will increase the symbol availability in **all** of them.
+
+```swift
+if #unavailable(iOS 9.0, *) {
+ // Symbol Availability: Default (deployment target)
+} else if a == b {
+ // Symbol Availability: iOS 9.0
+} else if b == c {
+ // Symbol Availability: iOS 9.0
+} else {
+ // Symbol Availability: iOS 9.0
+}
+```
+
+### Semantics of `*` for unavailability
+
+Availability statements are composed by a list of platform specs. The purpose of the list is to answer what's the platform version requirement necessary for the statement to return true in the platform where the code is being compiled.
+
+For this to work properly, the spec list must always contain an entry that matches the platform that's being compiled. An entry can be added to the list by either writing an explicit platform requirement (like `iOS 12`) or by using the generic platform wildcard `*`. Essentially, the wildcard signals that the expression being written is unrelated to the current platform, meaning that no version specification is needed. In practice, "no version specification needed" is done by treating the wildcard as the minimum deployment target of the platform, which essentially will cause the statement to never be false.
+
+```swift
+// Example: Code is compiling in iOS
+
+error: condition required for target platform 'iOS'
+if #available(macOS 11) {
+ ^
+
+/// Examples of possible solutions:
+if #available(macOS 11, *)
+if #available(macOS 11, iOS 12)
+if #available(iOS 12)
+// In practice, the last two will not compile due to an additional requirement that is mentioned below.
+```
+
+Even if you have no plans to use your code in a different platform, your statement must still define the wildcard as a way to define what should happen in all unspecified current and potential new future platforms. The compiler uses the wildcard to ease porting to new platforms -- because the platform being compiled must always have an entry in the spec list, the wildcard allows these platforms to compile your code without requiring a modification to every availability guard in the program. Additionally, because new platforms typically branch from existing platforms, the wildcard also makes sure these ported checks will always return `true` by default when checking for availability.
+
+It's important to note that availability spec lists **are not boolean expressions**. For example, it's not possible to add multiple versions of a platform to the statement:
+
+```swift
+if #available(iOS 12, *)
+if #available(iOS 12, iOS 13, *) // Error: Version for 'iOS' already specified
+```
+
+Additionally, the specification of different platforms have no effect on the final result -- it depends *only* on the (unique) spec that matches the current platform being compiled. A check like `#available(iOS 12, watchOS 4, *)` compiled in iOS doesn't mean "return true if (iOS 12 **||** watchOS 4 **||** the current platform's minimum deployment target) is available", it simply means "return true if iOS 12 is available". The specs that refer to different platforms are ignored.
+
+Finally, the wildcard represents *only* the platforms that were not explicitly specified in the spec list. When `#available(iOS 13, *)` is compiled for iOS, the wildcard will be ignored in favor of the explicitly defined iOS 13 spec. As mentioned before, a platform can only be mentioned once.
+
+For unavailability, the semantics mentioned above means that `#unavailable(*)` and `#unavailable(notWhatImCompiling X, *)` should do the opposite of `#available` and return `false`. Since the minimum deployment target will always be present, the statement can never be true. This behavior is exactly how the current workaround works, and it also matches how the theoretical `!#available(*)` would behave.
+
+```swift
+if #unavailable(*) {
+ // Will never be executed
+} else {
+ // ...
+}
+```
+
+As an interesting side effect, this means that having multiple unavailability checks in the same statement (`#unavailable(iOS 13, *), #unavailable(watchOS 3, *)` as opposed to `#unavailable(iOS 13, watchOS 3, *)`) would cause the statement to always be false if they are triggering the wildcard (in this case, because they cover different platforms).
+
+In these cases, since wildcard checks are eventually optimized to boolean literals, the compiler will already emit a warning indicating that the code will never be executed. Still, we could provide a more descriptive diagnostic that suggests using a single check that considers all platforms.
+
+```swift
+if #unavailable(iOS 13, *), #unavailable(watchOS 3, *) {
+ // ...
+ // Warning: code will never be executed
+ // Warning: unavailability checks in this statement are canceling each other, use a single check that treats all platforms
+ // fix-it: #unavailable(iOS 13, watchOS 3, *)
+}
+```
+
+### Result builders
+
+As `#unavailable` behaves exactly like `#available`, [`ViewBuilder`](https://developer.apple.com/documentation/swiftui/viewbuilder) does not need to be modified to support it. Using `#unavailable` on a builder will simply instead trigger [`buildLimitedAvailability(_:)`](0289-result-builders.md#availability) in the `else` block.
+
+## Source compatibility and ABI
+
+This change is purely additive.
+
+## Alternatives considered
+
+### `!#available(...)` and `#available(...) == false`
+
+While allowing the original condition to be reversed seems to be the obvious choice, supporting it in practice would require hardcoding all of this behavior as `#available` cannot be used as an expression. The author would rather not add tech debt to the compiler.
+
+Refactoring `#available` to be usable as an expression would likely require refactoring the entire symbol availability system and has an extensive amount of implications and edge cases. The work to support it would be considerably beyond what is proposed here.
+
+Supporting it by hardcoding this behavior is possible though, and could be implemented if the core team is willing and has a plan to eliminate the resulting tech debt in the future.
+
+On the other hand, given that it's fair to consider that this is a developer's first guess when attempting to do unavailability, the compiler will provide fix-its for each of these spellings.
+
+### `#unavailable(iOS 12)`, `#unavailable(iOS 12 && *)`, `#available(iOS < 12, *)` and other alternatives that involve reworking spec lists
+
+One point of discussion was the importance of the wildcard in the case of unavailability. Because the wildcard achieves nothing in terms of functionality, we considered alternatives that involved omitting or removing it completely. However, the wildcard is still important from a platform migration point of view, because although we don't need to force the guarded branch to be executed like in `#available`, the presence of the wildcard still play its intended role of allowing code involving unavailability statements to be ported to different platforms without requiring every single statement to be modified.
+
+Additionally, we had lengthy discussions about the *readability* of unavailability statements. We've noticed that even though availability in Swift has never been a boolean expression, it was clear that pretty much every developer's first instinct is to assume that `(iOS 12, *)` is equivalent to `iOS 12 || *`. The main point of discussion then was that the average developer might not understand why a call like `#unavailable(iOS 12, *)` will return `false` in non-iOS platforms, because they will assume the list means `iOS 12 || *` (`true`), while in reality (and as described in the `Semantics` section) the list means just `*` (`false`). During the pitch we tried to come up with alternatives that could eliminate this, and although some of them *did* succeed in doing that, they were doing so at the cost of making `#unavailable` "misleading", just like in the case of `!#available`. We ultimately decided that these improvements would be better suited for a *separate* proposal that focused on improving spec lists in general, which will be mentioned again at the end of this section.
+
+In general, there was much worry that this confusion could cause developers to misuse `#unavailable` and introduce bugs in their applications. We can prove that this feeling cannot happen in practice by how `#unavailable` doesn't introduce any new behavior -- it's nothing more than a reversed `#available` with a reversed literal name, which is semantically no different than the current workaround of using the `else` branch. Any confusing `#unavailable` scenario can also be conveyed as a confusing `#available` scenario by simply swapping the branches.
+
+Additionally, we were unable to locate concrete examples where this confusion could *actually* cause the feature to be misused. This is because if someone *does* misunderstand the branches, the project will simply fail to compile as there are symbols being used outside of an availability range. This was the case even when we tried to make the statements as vague as possible in an attempt to introduce a bug on purpose, and should hopefully make it clear for a confused developer that their code is simply upside-down.
+
+Although it's possible for developers to feel confused by the syntax, this is something that already exists with `#available` and cannot result in the feature being misused. As `#unavailable` does not introduces any new functionality that could change this, the author personally believes that this issue could be considered harmless and orthogonal to this proposal.
+
+However, we *do* have an unanimous agreement that spec lists can be confusing and that a new proposal should be created that re-evaluates how they are defined in code. Some members have also shared their belief that this re-evaluation should also happen *before* this proposal is introduced, which the author also agrees if there is a strong argument that `#unavailable` as is can be harmful for Swift.
diff --git a/proposals/0291-package-collections.md b/proposals/0291-package-collections.md
new file mode 100644
index 0000000000..19635a6616
--- /dev/null
+++ b/proposals/0291-package-collections.md
@@ -0,0 +1,342 @@
+# Package Collections
+
+* Proposal: [SE-0291](0291-package-collections.md)
+* Authors: [Boris Bügling](https://github.com/neonichu), [Yim Lee](https://github.com/yim-lee), [Tom Doron](https://github.com/tomerd)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Status: **Implemented (Swift 5.5)**
+* Implementation: [apple/swift-package-manager#3030](https://github.com/apple/swift-package-manager/pull/3030)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/7c45e22557a0ef726dea9787f0fae9dac3ed7856/proposals/0291-package-collections.md), [2](https://github.com/swiftlang/swift-evolution/blob/3e56b936a2398b7bd57c09dc39a845336d2543fe/proposals/0291-package-collections.md)
+* Review: [Review](https://forums.swift.org/t/se-0291-package-collections), [Review 2](https://forums.swift.org/t/se-0291-2nd-review-package-collections), [Acceptance](https://forums.swift.org/t/accepted-with-modifications-se-0291-package-collections), [Amendment](https://forums.swift.org/t/amendment-se-0291-package-collection-signing/), [Amendment Acceptance](https://forums.swift.org/t/accepted-se-0291-amendment-package-collection-signing/45126)
+
+## Introduction
+
+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.
+
+We believe there are three different components in the space of package discovery with different purposes:
+
+**Package Registry** is focused on hosting and serving package sources as an alternative to fetching them directly from git. The goal is to provide better immutability, durability and potentially improve performance and security. This initiative is in-progress and governed by [a separate proposal](https://github.com/swiftlang/swift-evolution/pull/1179).
+
+**Package Index** is focused for providing a search index for packages. The goal is to improve discoverability of packages that may be hosted anywhere, and provide a rich set of metadata that helps making informed decisions when choosing dependencies. The Index indexes the package core metadata available in `Package.swift` as well as additional metadata from additional and external sources. An example of a package index is https://swiftpackageindex.com.
+
+**Package Collections** which are the subject of this proposal are closer to the Package Index than to the Package Registry. Collections are also designed to make discovery easier, but focused on simpler curation lists that can be easily shared rather than on larger scale indexing and ranking system that requires infrastructure. This design is the first step in teaching SwiftPM about discovery of packages and future work to support Package Indexes can build on this initial design.
+
+
+## Motivation
+
+Currently, it can be difficult to discover packages that fit particular use cases. There is also no standardized way of accessing metadata about a package which is not part of the package manifest itself. We envision educators and community influencers publishing package collections to go along with course materials or blog posts, removing the friction of using packages for the first time and the cognitive overload of deciding which packages are useful for a particular task. We also envision enterprises using collections to narrow the decision space for their internal engineering teams, focusing them on a trusted set of vetted packages.
+
+Exposing the data of package collections via libSwiftPM and the `swift package-collection` command-line interface will also allow other tools to leverage this information and provide a richer experience for package discovery that is configured by the user in one central place.
+
+
+## Proposed solution
+
+We propose to introduce a new concept called **Package Collections** to the Swift package ecosystem. Collections are authored as static JSON documents and contain a list of packages and additional metadata per package. They are published to a web server or CDN-like infrastructure making them accessible to users. SwiftPM will gain new command-line interface for adding and removing collections and will index them in the background, allowing users to more easily discover and integrate packages that are included in the collections.
+
+For example, a course instructor knows they intend to teach with a set of several packages for their class. They can construct a collection JSON file, representing those packages. Then, they can post that JSON file to a GitHub repo or a website, giving the URL to that JSON file to all their students. Students use SwiftPM to add the instructor's collection to their SwiftPM configuration, and any packages the instructor puts into that collection can be easily used by the students.
+
+
+## Detailed design
+
+We propose to add a new sets of commands under a `swift package-collection` command-line interface that support the following workflows:
+
+1. Managing collections
+2. Querying metadata for individual packages
+3. Searching for packages and modules across collections
+
+We also propose adding a new per-user SwiftPM configuration file which will initially store the list of collections a user has configured, but can later be used for other per-user configuration for SwiftPM.
+
+### Example
+
+A course instructor shares a collection with packages needed for some assignments. The participants can add it to their set of collections:
+
+```
+$ swift package-collection add https://www.example.com/packages.json
+Added "Packages for course XYZ" to your package collections.
+```
+
+This will add the given collection to the user's set of collections for querying metadata and search.
+
+One of the assignments requires parsing a YAML file and instead of searching the web, participants can search the curated collection for packages that could help with their task:
+
+```
+$ swift package-collection search --keywords yaml
+https://github.com/jpsim/yams: A sweet and swifty YAML parser built on LibYAML.
+...
+```
+
+This will perform a string-based search across various metadata fields of all packages, such as the description and name. Results will contain URL and description (if any) of each match.
+
+Once a suitable package has been identified, there will also be the ability to query for more metadata, such as available versions, which will be required to actually depend on the package in practice.
+
+```
+$ swift package-collection describe https://github.com/jpsim/yams
+Description: A sweet and swifty YAML parser built on LibYAML.
+Available Versions: 4.0.0, 3.0.0, ...
+Watchers: 14
+Readme: https://github.com/jpsim/Yams/blob/master/README.md
+Authors: @norio-nomura, @jpsim
+--------------------------------------------------------------
+Latest Version: 4.0.0
+Package Name: Yams
+Modules: Yams, CYaml
+Supported Platforms: iOS, macOS, Linux, tvOS, watchOS
+Supported Swift Versions: 5.3, 5.2, 5.1, 5.0
+License: MIT
+CVEs: ...
+```
+
+This will list the basic metadata for the given package, as well as more detailed metadata for the latest version of the package. Available metadata for a package can incorporate data from the collection itself, as well as data discovered by SwiftPM. For example, by querying the package's repository or gathering data from the source code hosting platform being used by the package.
+
+
+
+### Manage Package Collections
+
+#### List
+
+The `list` command lists all collections that are configured by the user. The result can optionally be returned as JSON for integration into other tools.
+
+```
+$ swift package-collection list [--json]
+My organisation's packages - https://example.com/packages.json
+...
+```
+
+
+#### Manual refresh
+
+The `refresh` command refreshes any cached data manually. SwiftPM will also automatically refresh data under various conditions, but some queries such as search will rely on locally cached data.
+
+```
+$ swift package-collection refresh
+Refreshed 23 configured package collections.
+```
+
+
+#### Add
+
+The `add` command adds a collection by URL, with an optional order hint, to the user's list of configured collections. The order hint will influence ranking in search results and can also potentially be used by clients of SwiftPM to order results in a UI, for example.
+
+
+```
+$ swift package-collection add https://www.example.com/packages.json [--order N]
+Added "My organisation's packages" to your package collections.
+```
+
+
+#### Remove
+
+The `remove` command removes a collection by URL from the user's list of configured collections.
+
+```
+$ swift package-collection remove https://www.example.com/packages.json
+Removed "My organisation's packages" from your package collections.
+```
+
+
+#### Metadata and packages of a single collection
+
+The `describe` command shows the metadata and included packages for a single collection. This can be used for both collections that have been previously added to the list of the user's configured collections, as well as to preview any other collections.
+
+```
+$ swift package-collection describe https://www.example.com/packages.json
+Name: My organisation's packages
+Source: https://www.example.com/packages.json
+Description: ...
+Keywords: best, packages
+Created At: 2020-05-30 12:33
+Packages:
+ https://github.com/jpsim/yams
+ ...
+```
+
+
+
+### Get metadata for a single package
+
+Note: Collections will be limited in the number of major and minor versions they store per package. For each major/minor combination that is being stored, only data for the latest patch version will be present.
+
+#### Metadata for the package itself
+
+The `describe` command shows the metadata from the package itself. The result can optionally be returned as JSON for integration into other tools.
+
+```
+$ swift package-collection describe [--json] https://github.com/jpsim/yams
+Description: A sweet and swifty YAML parser built on LibYAML.
+Available Versions: 4.0.0, 3.0.0, ...
+Watchers: 14
+Readme: https://github.com/jpsim/Yams/blob/master/README.md
+Authors: @norio-nomura, @jpsim
+--------------------------------------------------------------
+Latest Version: 4.0.0
+Package Name: Yams
+Modules: Yams, CYaml
+Supported Platforms: iOS, macOS, Linux, tvOS, watchOS
+Supported Swift Versions: 5.3, 5.2, 5.1, 5.0
+License: MIT
+CVEs: ...
+```
+
+
+#### Metadata for a package version
+
+When passing an additional `--version` parameter, the `describe` command shows the metadata for a single package version. The result can optionally be returned as JSON for integration into other tools.
+
+```
+$ swift package-collection describe [--json] --version 4.0.0 https://github.com/jpsim/yams
+Package Name: Yams
+Version: 4.0.0
+Modules: Yams, CYaml
+Supported Platforms: iOS, macOS, Linux, tvOS, watchOS
+Supported Swift Versions: 5.3, 5.2, 5.1, 5.0
+License: MIT
+CVEs: ...
+```
+
+Note: since the `describe` action is shared between showing metadata for both whole collections as well as individual packages, it will first check if the given URL matches a known package and otherwise will treat the argument as a collection URL. If the `--version` parameter is passed, the collection fallback will not be done since the user already explicitly requested information about a package.
+
+
+
+### Search
+
+#### String-based search
+
+The search command does a string-based search when using the `--keyword` option and returns the list of packages that match the query. The result can optionally be returned as JSON for integration into other tools.
+
+```
+$ swift package-collection search [--json] --keywords yaml
+https://github.com/jpsim/yams: A sweet and swifty YAML parser built on LibYAML.
+...
+```
+
+
+#### Module-based search
+
+The search command does a search for a specific module name when using the `--module` option. The result can optionally be returned as JSON for integration into other tools. Lists the newest version the matching module can be found in. This will display more metadata per package than the string-based search as we expect just one or very few results for packages with a particular module name.
+
+```
+$ swift package-collection search [--json] --module yams
+Package Name: Yams
+Latest Version: 4.0.0
+Description: A sweet and swifty YAML parser built on LibYAML.
+--------------------------------------------------------------
+...
+```
+
+
+
+### Configuration file
+
+The global configuration file will be expected at this location:
+
+
+```
+~/.swiftpm/config
+```
+
+
+This file will be stored in a `.swiftpm` directory in the user's home directory (or its equivalent on the specific platform SwiftPM is running on).
+
+This file will be managed through SwiftPM commands and users are not expected to edit it by hand. The format of this file is an implementation detail but it will be human readable format, likely JSON in practice.
+
+There could be a supplemental file providing key-value pairs whose keys can be referenced by the main configuration file. This can be used as an override mechanism that allows sharing the main configuration file between different users and machines by keeping user-specific configuration information out of the main configuration file. The use of this additional file will be optional and it will be managed by the user. The syntax of the format will be based on git's configuration files, described [here](https://git-scm.com/docs/git-config#_syntax), but it will not support all of its semantics.
+
+
+### Data format
+
+Package collections must adhere to a specific JSON format for SwiftPM to be able to consume them. The current proposed JSON format can be found [here](https://github.com/apple/swift-package-collection-generator/blob/main/PackageCollectionFormats/v1.md). It is not part of this proposal because it is not considered stable API. Over time as the data format matures, we will consider making it stable API in a separate proposal.
+
+Since the data format is unstable, users should avoid generating package collections on their own. This proposal includes providing the necessary [tooling](https://github.com/apple/swift-package-collection-generator) for package collection generations.
+
+### Package collection signing
+
+Package collections can be signed to establish authenticity and protect their integrity. Doing this is optional and users will not be blocked from adding unsigned package collections.
+
+There will be [tooling](https://github.com/apple/swift-package-collection-generator) to help publishers sign their package collections. To generate a signature one must provide:
+- The package collection file to be signed
+- A code signing certificate
+- The certificate's private key
+- The certificate's chain in its entirety
+
+The signature will include the certificate's public key and chain so that they can be used for verification later.
+
+A signed package collection will have an extra `signature` object:
+
+```
+{
+ // Package collection JSON
+ ...,
+ "signature": {
+ ...
+ }
+}
+```
+
+#### Requirements on signing certificate
+
+The following conditions are checked and enforced during signature generation and verification:
+- The timestamp at which signing/verification is done must fall within the signing certificate's validity period.
+- The certificate's "Extended Key Usage" extension must include "Code Signing".
+- The certificate must use either 256-bit EC (recommended) or 2048-bit RSA key.
+- The certificate must not be revoked. The certificate authority must support OCSP, which means the certificate must have the "Certificate Authority Information Access" extension that includes OCSP as a method, specifying the responder's URL.
+- The certificate chain is valid and root certificate must be trusted.
+
+##### Trusted root certificates
+
+On Apple platforms, all root certificates that come preinstalled with the OS are automatically trusted. Users may specify additional certificates to trust by placing them in the `~/.swiftpm/config/trust-root-certs` directory.
+
+On non-Apple platforms, there are no trusted root certificates by default. Only those found in `~/.swiftpm/config/trust-root-certs` are trusted.
+
+#### Add a signed package collection
+
+When adding a signed package collection, SwiftPM will check that:
+- The file content (excluding `signature`) is what was used to generate the signature. In other words, this checks to see if the collection has been altered since it was signed.
+- The signing certificate meets all of the [requirements](#requirements-on-signing-certificate).
+
+SwiftPM will not import a collection if any of these checks fails.
+
+User may opt to skip the signature check on a collection by passing the `--skip-signature-check` flag during `add`:
+
+```bash
+$ swift package-collection add https://www.example.com/packages.json --skip-signature-check
+```
+
+Since there are no trusted root certificates by default on non-Apple platforms, the signature check will always fail. SwiftPM will detect this and instruct user to either set up the `~/.swiftpm/config/trust-root-certs` directory or use `--skip-signature-check`.
+
+#### Add an unsigned package collection
+
+When adding an unsigned package collection, user must confirm their trust by passing the `--trust-unsigned` flag:
+
+```bash
+$ swift package-collection add https://www.example.com/unsigned-packages.json --trust-unsigned
+```
+
+The `--skip-signature-check` flag has no effects on unsigned collections.
+
+#### Security risks
+
+Signed package collections as currently designed are susceptible to the following attack vectors:
+
+- **Signature stripping**: This involves attackers removing signature from a signed collection, causing it to be downloaded as an unsigned collection and bypassing signature check. In this case, publishers should make it known that the collection is signed, and users should abort the `add` operation when the "unsigned" warning shows up on a supposedly signed collection.
+- **Signature replacement**: Attackers may modify a collection then re-sign it using a different certificate, and SwiftPM will accept it as long as the signature is valid.
+
+To defend against these attacks, SwiftPM will offer a way for collection publishers to:
+1. Require signature check on their collections - this defends against "signature stripping".
+2. Restrict what certificate can be used for signing - this defends against "signature replacement".
+
+The process will involve submitting a pull request to modify SwiftPM certificate pinning configuration.
+
+## Future direction
+
+This proposal shows an initial set of metadata that package collections will offer, but the exact metadata provided can be evolved over time as needed. The global configuration files introduced here can be used for future features which require storing per-user configuration data.
+
+This design is the first step in teaching SwiftPM about sets of curated packages, with the goal of allowing the community to build trusted working-sets of packages. Future work to support more dynamic server-based indexes can build on this initial design.
+
+
+## Impact on existing packages
+
+There is no impact on existing packages as this is a discovery feature that's being added to SwiftPM's command-line interface.
+
+
+## Alternatives considered
+
+The initial pitch considered adding the new CLI functionality under the existing `swift package` command, but that caused deeper nesting of commands and also did not fit with the existing functionality under this command.
diff --git a/proposals/0292-package-registry-service.md b/proposals/0292-package-registry-service.md
new file mode 100644
index 0000000000..a981a2b4cf
--- /dev/null
+++ b/proposals/0292-package-registry-service.md
@@ -0,0 +1,1267 @@
+# Package Registry Service
+
+* Proposal: [SE-0292](0292-package-registry-service.md)
+* Authors: [Bryan Clark](https://github.com/clarkbw),
+ [Whitney Imura](https://github.com/whitneyimura),
+ [Mattt Zmuda](https://github.com/mattt)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Status: **Implemented (Swift 5.7)**
+* Implementation: [apple/swift-package-manager#3023](https://github.com/apple/swift-package-manager/pull/3023)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0292-package-registry-service/49849)
+* Review:
+ [1](https://forums.swift.org/t/se-0292-package-registry-service/)
+ [2](https://forums.swift.org/t/se-0292-2nd-review-package-registry-service/)
+ [3](https://forums.swift.org/t/se-0292-3rd-review-package-registry-service/)
+ [Amendment](https://forums.swift.org/t/amendment-se-0292-package-registry-service/)
+* Previous Revision:
+ [1](https://github.com/swiftlang/swift-evolution/blob/b48527526b5748a60b0b23846d5880e9cc2c4711/proposals/0292-package-registry-service.md)
+ [2](https://github.com/swiftlang/swift-evolution/blob/53bd6d3813c40ebd07701727c8cfb6fedd751e2a/proposals/0292-package-registry-service.md)
+ [3](https://github.com/swiftlang/swift-evolution/blob/971d1f43bce718a45227432782a312cc5de99870/proposals/0292-package-registry-service.md)
+
+## Introduction
+
+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.
+
+Swift-evolution thread:
+[Swift Package Registry Service](https://forums.swift.org/t/swift-package-registry-service/37219)
+
+## Motivation
+
+A package dependency is currently specified by a URL to its source repository.
+When Swift Package Manager builds a project for the first time,
+it clones the Git repository for each dependency
+and attempts to resolve the version requirements from the available tags.
+
+Although Git is a capable version-control system,
+it's not well-suited to this kind of workflow for the following reasons:
+
+* **Reproducibility**:
+ A version tag in the Git repository for a dependency
+ can be reassigned to another commit at any time.
+ This can cause a project to produce different build results
+ depending on when it was built.
+* **Availability**:
+ The Git repository for a dependency can be moved or deleted,
+ which can cause subsequent builds to fail.
+* **Efficiency**:
+ Cloning the Git repository for a dependency
+ downloads all versions of a package when only one is used at a time.
+* **Speed**:
+ Cloning a Git repository for a dependency can be slow
+ if it has a large history.
+ Also, cloning a Git repository is expensive for both the server and client,
+ and may be significantly slower than downloading the same content
+ using HTTP through a [content delivery network (CDN)][CDN].
+
+Many language ecosystems have a *package registry*, including
+[RubyGems] for Ruby,
+[PyPI] for Python,
+[npm] for JavaScript, and
+[crates.io] for Rust.
+In fact,
+many Swift developers build apps today using
+[CocoaPods] and its index of libraries.
+
+A package registry for Swift Package Manager
+could offer faster and more reliable dependency resolution
+than downloading dependencies using Git.
+It could also support other useful functionality,
+including package search, security audits, and local offline caches.
+
+## Proposed solution
+
+This proposal defines a standard interface for package registry services
+and describes how Swift Package Manager integrates with them
+to download dependencies.
+
+A user may [configure](#registry-configuration-subcommands)
+a package registry for their project
+by specifying a URL to a [conforming web service](#package-registry-service-1).
+When a registry is configured,
+Swift Package Manager resolves external dependencies
+in the project's package manifest (`Package.swift`) file
+that are [declared](#new-packagedescription-api)
+with a [scoped package identifier](#package-identity) in the form
+`scope.package-name`.
+These package identifiers resolve potential
+[name collisions](#package-name-collision-resolution)
+across build targets.
+
+For each external dependency declared in the package manifest,
+Swift Package Manager first sends a
+`GET` request to `/{scope}/{name}`
+to fetch a list of available releases
+from the configured registry.
+If a release is found that satisfies the declared version requirement
+(for example, `.upToNextMinor(from: "1.1.0")`),
+Swift Package Manager sends a
+`GET` request to `/{scope}/{name}/{version}/Package.swift`
+to fetch the manifest for that release.
+This process continues with the package manifests of each dependency,
+each of their respective dependencies,
+and so on.
+Once the dependency graph is [resolved](#dependency-graph-resolution),
+Swift Package Manager downloads the
+[source archive](#archive-source-subcommand) for each dependency
+by sending a `GET` request to `/{scope}/{name}/{version}.zip`.
+
+## Detailed design
+
+### Package registry service
+
+A package registry service implements the following REST API endpoints
+for listing releases for a package,
+fetching information about a release,
+and downloading the source archive for a release:
+
+| Method | Path | Description |
+| ------ | --------------------------------------------------------- | ----------------------------------------------- |
+| `GET` | `/{scope}/{name}` | List package releases |
+| `GET` | `/{scope}/{name}/{version}` | Fetch metadata for a package release |
+| `GET` | `/{scope}/{name}/{version}/Package.swift{?swift-version}` | Fetch manifest for a package release |
+| `GET` | `/{scope}/{name}/{version}.zip` | Download source archive for a package release |
+| `GET` | `/identifiers{?url}` | Lookup package identifiers registered for a URL |
+
+A formal specification for the package registry interface is provided
+[alongside this proposal](https://github.com/apple/swift-package-manager/blob/main/Documentation/PackageRegistry/Registry.md).
+In addition,
+an OpenAPI (v3) document
+and a reference implementation written in Swift
+are provided for the convenience of developers interested
+in building their own package registry.
+
+### Changes to Swift Package Manager
+
+#### Package identity
+
+Currently, the identity of a package is computed from
+the last path component of its effective URL
+(which can be changed with dependency mirroring).
+However, this approach can lead to a conflation of
+distinct packages with similar names
+and the duplication of the same package under different names.
+
+We propose using a scoped identifier
+in the form `scope.package-name`
+to identify package dependencies.
+
+A *scope* provides a namespace for related packages within a package registry.
+A package scope consists of
+alphanumeric characters and hyphens.
+Hyphens may not occur at the beginning or end,
+nor consecutively within a scope.
+The maximum length of a package scope is 39 characters.
+A valid package scope matches the following regular expression pattern:
+
+```regexp
+\A[a-zA-Z\d](?:[a-zA-Z\d]|-(?=[a-zA-Z\d])){0,38}\z
+```
+
+A package's *name* uniquely identifies a package in a scope.
+A package name consists of alphanumeric characters, underscores, and hyphens.
+Hyphens and underscores may not occur at the beginning or end,
+nor consecutively within a name.
+The maximum length of a package name is 100 characters.
+A valid package scope matches the following regular expression pattern:
+
+```regexp
+\A[a-zA-Z0-9](?:[a-zA-Z0-9]|[-_](?=[a-zA-Z0-9])){0,99}\z
+```
+
+Package scopes and names are compared using locale-independent case folding.
+
+#### New `PackageDescription` API
+
+The `Package.Dependency` type adds the following static method:
+
+```swift
+extension Package.Dependency {
+ /// Adds a dependency on a package with the specified identifier
+ /// that uses the provided version requirement.
+ public static func package(
+ id: String,
+ _ requirement: Package.Dependency.VersionBasedRequirement
+ ) -> Package.Dependency
+}
+```
+
+These methods may be called in the `dependencies` field of a package manifest
+to declare one or more dependencies by their respective package identifier.
+
+```swift
+dependencies: [
+ .package(id: "mona.LinkedList", .upToNextMinor(from: "1.1.0")),
+ .package(id: "mona.RegEx", .exact("2.0.0"))
+]
+```
+
+A package dependency declared with an identifier using this method
+may only specify a version-based requirement.
+`Package.Dependency.VersionBasedRequirement` is a new type
+that provides the same interface as `Package.Dependency.Requirement`
+for version-based requirements,
+but excluding branch-based and commit-based requirements.
+
+#### Package name collision resolution
+
+Consider a dependency graph that includes both
+a package declared with the identifier `mona.LinkedList` and
+an equivalent package declared with the URL `https://github.com/mona/LinkedList`.
+
+When Swift Package Manager fetches a list of releases for the identified package
+(`GET /mona/LinkedList`),
+the response includes a `Link` header field
+with URLs to that project's source repository
+that are known to the registry.
+
+```http
+Link: ; rel="canonical",
+ ; rel="alternate"
+```
+
+Swift Package Manager uses this information
+to reconcile the URL-based dependency declaration with
+the package identifier `mona.LinkedList`.
+Link relation URLs may also be normalized to mitigate insignificant variations.
+For example,
+a package with an ["scp-style" URL][scp-url] like
+`git@github.com:mona/LinkedList.git`
+is determined to be equivalent to a URL with an explicit scheme like
+`ssh:///git@github.com/mona/LinkedList`.
+Swift Package Manager may additionally consult the registry
+to associate a URL-based package declaration with a package identifier
+by sending a `GET /identifiers{?url}` request with that package's URL.
+
+A package identifier serves as the package name
+in target-based dependency declarations —
+that is, the `package` parameter in `.product(name:package)` method calls.
+
+```diff
+ targets: [
+ .target(name: "MyLibrary",
+ dependencies: [
+ .product(name: "LinkedList",
+- package: "LinkedList")
++ package: "mona.LinkedList")
+ ]
+ ]
+```
+
+Any path-based dependency declaration
+or URL-based declaration without an associated package identifier
+will continue to synthesize its identity from
+the last path component of its location.
+
+#### Dependency graph resolution
+
+In its `PackageGraph` module, Swift Package Manager defines
+the `PackageContainer` protocol as the top-level unit of package resolution.
+Conforming types are responsible for
+determining the available tags for a package
+and its contents at a particular revision.
+A `PackageContainerProvider` protocol adds a level of indirection
+for resolving package containers.
+
+There are currently two concrete implementations of `PackageContainer`:
+`LocalPackageContainer` and `RepositoryPackageContainer`.
+This proposal adds a new `RegistryPackageContainer` type
+that adopts `PackageContainer`
+and performs equivalent operations with HTTP requests to a registry service.
+These client-server interactions are facilitated by
+a new `RegistryManager` type.
+When requesting resources from a registry,
+Swift Package Manager will employ techniques like
+exponential backoff, circuit breakers, and client-side validation
+to safeguard against adverse network conditions and malicious server responses.
+
+The following table lists the
+tasks performed by Swift Package Manager during dependency resolution
+alongside the Git operations used
+and their corresponding package registry API calls.
+
+| Task | Git operation | Registry request |
+| ------------------------------------- | --------------------------- | --------------------------------------------- |
+| Fetch the contents of a package | `git clone && git checkout` | `GET /{scope}/{name}/{version}.zip` |
+| List the available tags for a package | `git tag` | `GET /{scope}/{name}` |
+| Fetch a package manifest | `git clone` | `GET /{scope}/{name}/{version}/Package.swift` |
+
+Package registries support
+[version-specific _manifest_ selection][version-specific-manifest-selection]
+by providing a list of versioned manifest files for a package
+(for example, `Package@swift-5.3.swift`)
+in its response to `GET /{scope}/{name}/{version}/Package.swift`.
+However, package registries don't support
+[version-specific _tag_ selection][version-specific-tag-selection].
+
+### Changes to `Package.resolved`
+
+Swift package registry releases are archived as Zip files.
+
+When an external package dependency is downloaded through a registry,
+Swift Package Manager compares the integrity checksum provided by the server
+against any existing checksum for that release in the `Package.resolved` file
+as well as the integrity checksum reported by the `compute-checksum` subcommand:
+
+```console
+$ swift package compute-checksum LinkedList-1.2.0.zip
+1feec3d8d144814e99e694cd1d785928878d8d6892c4e59d12569e179252c535
+```
+
+If no prior checksum exists,
+it's saved to `Package.resolved`.
+
+```json
+{
+ "object": {
+ "pins": [
+ {
+ "package": "mona.LinkedList",
+ "state": {
+ "checksum": "ed008d5af44c1d0ea0e3668033cae9b695235f18b1a99240b7cf0f3d9559a30d",
+ "version": "1.2.0"
+ }
+ }
+ ]
+ },
+ "version": 1
+}
+```
+
+Suppose the checksum reported by the server
+is different from the existing checksum
+(or the checksum of the downloaded artifact is different from either of them).
+In that case,
+a package's contents may have changed at some point.
+Swift Package Manager will refuse to download dependencies
+if there's a mismatch in integrity checksums.
+
+```console
+$ swift build
+error: checksum of downloaded source archive of dependency 'mona.LinkedList' (c2b934fe66e55747d912f1cfd03150883c4f037370c40ca2ad4203805db79457) does not match checksum specified by the manifest (ed008d5af44c1d0ea0e3668033cae9b695235f18b1a99240b7cf0f3d9559a30d)
+```
+
+Once the correct checksum is determined,
+the user can update `Package.resolved` with the correct value
+and try again.
+
+### Archive-source subcommand
+
+An anecdotal look at other package managers suggests that
+a checksum mismatch is more likely to be a
+disagreement in how to create the archive and/or calculate the checksum
+than, say, a forged or corrupted package.
+
+This proposal adds a new `swift package archive-source` subcommand
+to provide a standard way to create source archives for package releases.
+
+```manpage
+SYNOPSIS
+ swift package archive-source [--output=]
+
+OPTIONS
+ -o , --output=
+ Write the archive to .
+ If unspecified, the package is written to `\(PackageName).zip`.
+```
+
+Run the `swift package archive-source` subcommand
+in the root directory of a package
+to generate a source archive for the current working tree.
+For example:
+
+```console
+$ tree -a -L 1
+LinkedList
+├── .git
+├── Package.swift
+├── README.md
+├── Sources
+└── Tests
+
+$ head -n 5 Package.swift
+// swift-tools-version:5.3
+import PackageDescription
+
+let package = Package(
+name: "LinkedList",
+
+$ swift package archive-source
+Created LinkedList.zip
+```
+
+By default,
+generated archive's filename is
+the name of the package with a `.zip` extension
+(for example, "LinkedList.zip").
+You can override this behavior with the `--output` option:
+
+```console
+$ git checkout 1.2.0
+$ swift package archive-source --output="LinkedList-1.2.0.zip"
+# Created LinkedList-1.2.0.zip
+```
+
+The `archive-source` subcommand has the equivalent behavior of
+[`git-archive(1)`] using the `zip` format at its default compression level,
+with entries prefixed by the basename of the generated archive's filename.
+Therefore, the following command produces
+equivalent output to the previous example:
+
+```console
+$ git archive --format zip \
+ --prefix LinkedList-1.2.0
+ --output LinkedList-1.2.0.zip \
+ 1.2.0
+```
+
+If desired, this behavior could be changed in future tool versions.
+
+> **Note**:
+> `git-archive` ignores files with the `export-ignore` Git attribute.
+> By default, this ignores hidden files and directories,
+> including`.git` and `.build`.
+
+### Registry configuration subcommands
+
+This proposal adds a new `swift package-registry` subcommand
+for managing the registry used for all packages
+and/or packages in a particular scope.
+
+Custom registries can serve a variety of purposes:
+
+- **Private dependencies**:
+ Users may configure a custom registry for a particular scope
+ to incorporate private packages with those fetched from a public registry.
+- **Geographic colocation**:
+ Developers working under adverse networking conditions can
+ host a mirror of official package sources on a nearby network.
+- **Policy enforcement**:
+ A corporate network can enforce quality or licensing standards,
+ so that only approved packages are available through a custom registry.
+- **Auditing**:
+ A custom registry may analyze or meter access to packages
+ for the purposes of ranking popularity or charging licensing fees.
+
+#### Setting a custom registry
+
+```manpage
+SYNOPSIS
+ swift package-registry set [options]
+OPTIONS:
+ --global Apply settings to all projects for this user
+ --scope Associate the registry with a given scope
+ --login Specify a user name for the remote machine
+ --password Supply a password for the remote machine
+```
+
+Running the `package-registry set` subcommand
+in the root directory of a package
+creates or updates the `.swiftpm/configuration/registries.json` file
+with a new top-level `registries` key
+that's associated with an object containing the specified registry URLs.
+The default, unscoped registry is associated with the key `[default]`.
+Any scoped registries are keyed by their case-folded name.
+
+For example,
+a build server that doesn't allow external network connections
+may configure a registry URL to resolve dependencies
+using an internal registry service.
+
+```console
+$ swift package-registry set https://internal.example.com/
+$ cat .swiftpm/configuration/registries.json
+```
+
+```json
+{
+ "registries": {
+ "[default]": {
+ "url": "https://internal.example.com"
+ }
+ },
+ "version": 1
+}
+
+```
+
+If no registry is configured,
+Swift Package Manager commands like
+`swift package resolve` and `swift package update`
+fail with an error.
+
+```console
+$ swift package resolve
+error: cannot resolve dependency 'mona.LinkedList' without a configured registry
+```
+
+#### Associating a registry with a scope
+
+The user can associate a package scope with a custom registry
+by passing the `--scope` option.
+
+For example,
+a user might resolve all packages with the package scope `example`
+(such as `example.PriorityQueue`)
+to a private registry.
+
+```console
+$ swift package-registry set https://internal.example.com/ --scope example
+$ cat .swiftpm/configuration/registries.json
+```
+
+```json
+{
+ "registries": {
+ "example": {
+ "url": "https://internal.example.com"
+ }
+ },
+ "version": 1
+}
+
+```
+
+When a custom registry is associated with a package scope,
+package dependencies with that scope are resolved through the provided URL.
+A custom registry may be associated with one or more scopes,
+but a scope may be associated with only a single registry at a time.
+Scoped custom registries override any unscoped custom registry.
+
+#### Unsetting a custom registry
+
+This proposal also adds a new `swift package-registry unset` subcommand
+to complement the `package-registry set` subcommand.
+
+```manpage
+SYNOPSIS
+ swift package-registry unset [options]
+OPTIONS:
+ --global Apply settings to all projects for this user
+ --scope Removes the registry's association to a given scope
+```
+
+Running the `package-registry unset` subcommand
+in the root directory of a package
+updates the `.swiftpm/configuration/registries.json` file
+to remove the `default` entry in the top-level `registries` key, if present.
+If a `--scope` option is passed,
+only the entry for the specified scope is removed, if present.
+
+#### Global registry configuration
+
+The user can pass the `--global` option to the `set` or `unset` subcommands
+to update the user-level configuration file located at
+`~/.swiftpm/configuration/registries.json`.
+
+Any default or scoped registries configured locally in a project directory
+override any values configured globally for the user.
+For example,
+consider the following global and local registry configuration files:
+
+```jsonc
+// Global configuration (~/.swiftpm/configuration/registries.json)
+{
+ "registries": {
+ "[default]": {
+ "url": "https://global.example.com"
+ },
+ "foo": {
+ "url": "https://global.example.com"
+ },
+ },
+ "version": 1
+}
+
+// Local configuration (.swiftpm/configuration/registries.json)
+{
+ "registries": {
+ "foo": {
+ "url": "https://local.example.com"
+ }
+ },
+ "version": 1
+}
+
+```
+
+Running the `swift package resolve` command with these configuration files
+resolves packages with the `foo` scope
+using the registry located at "https://local.example.com",
+and all other packages
+using the registry located at "https://global.example.com".
+
+In summary,
+the behavior of `swift package resolve` and related commands
+depends on the following factors,
+in descending order of precedence:
+
+* The package manifest in the current directory (`./Package.swift`)
+* Any existing lock file (`./Package.resolved`)
+* Any local configuration (`./.swiftpm/configuration/registries.json`)
+* Any global configuration file (`~/.swiftpm/configuration/registries.json`)
+
+#### Specifying credentials for a custom registry
+
+Some servers may require a username and password.
+The user can provide credentials when setting a custom registry
+by passing the `--login` and `--password` options.
+
+When credentials are provided,
+the corresponding object in the `registries.json` file
+includes a `login` key with the passed value.
+If the project's `.netrc` file has an existing entry
+for a given machine and login,
+it's updated with the new password;
+otherwise, a new entry is added.
+If no `.netrc` file exists,
+a new one is created and populated with the new entry.
+
+```console
+$ swift package-registry set https://internal.example.com/ \
+ --login jappleseed --password alpine
+
+$ cat .netrc
+machine internal.example.com
+login jappleseed
+password alpine
+
+$ cat .swiftpm/configuration/registries.json
+
+{
+ "registries": {
+ "[default]": {
+ "url": "https://internal.example.com"
+ "login": "jappleseed"
+ }
+ },
+ "version": 1
+}
+```
+
+If the user passes the `--login` and `--password` options
+to the `set` subcommand along with the `--global` option,
+the user-level `.netrc` file is updated instead.
+When Swift Package Manager connects to a custom registry,
+it first consults the project's `.netrc` file, if one exists.
+If no entry is found for the custom registry,
+Swift Package Manager then consults the user-level `.netrc` file, if one exists.
+
+If the provided credentials are missing or invalid,
+Swift Package Manager commands like
+`swift package resolve` and `swift package update`
+fail with an error.
+
+### Changes to config subcommand
+
+#### Set-mirror option for package identifiers
+
+A user can currently specify an alternate location for a package
+by setting a [dependency mirror][SE-0219] for that package's URL.
+
+```console
+$ swift package config set-mirror \
+ --original-url https:///github.com/mona/linkedlist \
+ --mirror-url https:///github.com/octocorp/swiftlinkedlist
+```
+
+This proposal updates the `swift package config set-mirror` subcommand
+to accept a `--package-identifier` option in place of an `--original-url`.
+Running this subcommand with a `--package-identifier` option
+creates or updates the `.swiftpm/configuration/mirrors.json` file,
+modifying the array associated with the top-level `object` key
+to add a new entry or update an existing entry
+for the specified package identifier,
+that assigns its alternate location.
+
+```json
+{
+ "object": [
+ {
+ "mirror": "https://github.com/OctoCorp/SwiftLinkedList.git",
+ "original": "mona.LinkedList"
+ }
+ ],
+ "version": 1
+}
+
+```
+
+When a mirror URL is set for a package identifier,
+Swift Package Manager resolves any dependencies with that identifier
+through Git using the provided URL.
+
+## Security
+
+Adding external dependencies to a project
+increases the attack surface area of your software.
+However, much of the associated risk can be mitigated,
+and a package registry can offer stronger guarantees for safety and security
+compared to downloading dependencies using Git.
+
+Core security measures,
+such as the use of HTTPS and integrity checksums,
+are required by the registry service specification.
+Additional decisions about security
+are delegated to the registries themselves.
+For example,
+registries are encouraged to adopt a
+scoped, revocable authorization framework like [OAuth 2.0][RFC 6749],
+but this isn't a strict requirement.
+Package maintainers and consumers should
+consider a registry's security posture alongside its other features
+when deciding where to host and fetch packages.
+
+Our proposal's package identity scheme is designed to prevent or mitigate
+vulnerabilities common to packaging systems and networked applications:
+
+- Package scopes are restricted to a limited set of characters,
+ preventing [homograph attacks].
+ For example,
+ "А" (U+0410 CYRILLIC CAPITAL LETTER A) is an invalid scope character
+ and cannot be confused for "A" (U+0041 LATIN CAPITAL LETTER A).
+- Package scopes disallow leading, trailing, or consecutive hyphens (`-`),
+ and disallows underscores (`_`) entirely,
+ which mitigates look-alike package scopes
+ (for example, "llvm--swift" and "llvm_swift" are both invalid
+ and cannot be confused for "llvm-swift").
+- Package scopes disallow dots (`.`),
+ which prevents potential confusion with domain variants of scopes
+ (for example, "apple.com" is invalid
+ and cannot be confused for "apple").
+- Packages are registered within a scope,
+ which mitigates [typosquatting].
+ Package registries may further restrict the assignment of new scopes
+ that are intentionally misleading
+ (for example, "G00gle", which looks like "Google").
+- Package names disallow punctuation and whitespace characters used in
+ [cross-site scripting][xss] and
+ [CRLF injection][http header injection] attacks.
+
+To better understand the security implications of this proposal —
+and Swift dependency management more broadly —
+we employ the
+
+[STRIDE]
+ mnemonic below:
+
+### Spoofing
+
+An attacker could interpose a proxy between the client and the package registry
+to intercept credentials for that host
+and use them to impersonate the user in subsequent requests.
+
+The impact of this attack is potentially high,
+depending on the scope and level of privilege associated with these credentials.
+However, the use of secure connections over HTTPS
+goes a long way to mitigate the overall risk.
+
+Swift Package Manager could further mitigate this risk
+by taking the following measures:
+
+* Enforcing HTTPS for all URLs
+* Resolving URLs using DNS over HTTPS (DoH)
+* Requiring URLs with Internationalized Domain Names (IDNs)
+ to be represented as Punycode
+
+### Tampering
+
+An attacker could interpose a proxy between the client and the package registry
+to construct and send Zip files containing malicious code.
+
+Although the impact of such an attack is potentially high,
+the risk is largely mitigated by the use of cryptographic checksums
+to verify the integrity of downloaded source archives.
+
+```console
+$ echo "$(swift package compute-checksum LinkedList-1.2.0.zip) *LinkedList-1.2.0.zip" | \
+ shasum -a 256 -c -
+LinkedList-1.2.0.zip: OK
+```
+
+Integrity checks alone can't guarantee
+that a package isn't a forgery;
+an attacker could compromise the website of the host
+and provide a valid checksum for a malicious package.
+
+`Package.resolved` provides a [Trust on first use (TOFU)][TOFU] security model
+that can offer strong guarantees about the integrity of dependencies over time.
+A registry can further improve on this model by implementing a
+[transparent log],
+[checksum database],
+or another comparable, tamper-proof system
+for authenticating package contents.
+
+Distribution of packages through Zip files
+introduces new potential attack vectors.
+For example,
+an attacker could maliciously tamper with a generated source archive
+in an attempt to exploit
+a known vulnerability like [Zip Slip],
+or a common software weakness like susceptibility to a [Zip bomb].
+Swift Package Manager should take care to
+identify and protect against these kinds of attacks
+in its implementation of source archive decompression.
+
+### Repudiation
+
+A compromised host could serve a malicious package with a valid checksum
+and be unable to deny its involvement in constructing the forgery.
+
+This threat is unique and specific to binary and source artifacts;
+Git repositories can have their histories audited,
+and individual commits may be cryptographically signed by authors.
+Unless you can establish a direct connection between
+an artifact and a commit in a source tree,
+there's no way to determine the provenance of that artifact.
+
+Source archives generated by [`git-archive(1)`]
+include the checksum of the `HEAD` commit as a comment.
+If the history of a project is available
+and the commit used to generate the source archive is signed with [GPG],
+the cryptographic signature may be used to verify the authenticity.
+
+```console
+$ git rev-parse HEAD
+b7c37c81f164e5dce0f64e3d75c79a48fb1fe00b3
+
+$ swift package archive-source -o LinkedList-1.2.0.zip
+Generated LinkedList-1.2.0.zip
+
+$ zipnote LinkedList-1.2.0.zip | grep "@ (zip file comment below this line)" -A 1 | tail -n 1
+b7c37c81f164e5dce0f64e3d75c79a48fb1fe00b3
+
+$ git verify-commit b7c37c81f164e5dce0f64e3d75c79a48fb1fe00b3
+gpg: Signature made Tue Dec 16 00:00:00 2020 PST
+gpg: using RSA key BFAA7114B920808AA4365C203C5C1CF
+gpg: Good signature from "Mona Lisa Octocat " [ultimate]
+```
+
+Otherwise,
+a checksum database and the use of digital signatures
+can both provide similar non-repudiation guarantees.
+
+### Information disclosure
+
+A user may inadvertently expose credentials
+by checking in their project's configuration files.
+An attacker could scrape public code repositories for configuration files
+and attempt to reuse credentials to impersonate the user.
+
+The risk of leaking credentials can be mitigated by
+storing them in a `.netrc` file located outside the project directory
+(typically in the user's home directory).
+However,
+a user may run `swift package` subcommands with the `--netrc-file` option
+to configure the location of their project's `.netrc` file.
+To mitigate the risk of a user inadvertently
+adding a local `.netrc` file to version control,
+Swift Package Manager could add an entry to the `.gitignore` file template
+for new projects created with `swift package init`.
+
+Code hosting providers can also help minimize this risk
+by [detecting secrets][secret scanning]
+that are committed to public repositories.
+
+Credentials may also be unintentionally disclosed
+by Swift Package Manager or other tools in logging statements.
+Care should be taken to redact usernames and passwords
+when displaying feedback to the user.
+
+### Denial of service
+
+An attacker could scrape public code repositories
+for `.swiftpm/configuration/registries.json` files
+that declare one or more custom registries
+and launch a denial-of-service attack
+in an attempt to reduce the availability of those resources.
+
+```json
+{
+ "registries": {
+ "[default]": {
+ "url": "https://private.example.com"
+ }
+ },
+ "version": 1
+}
+
+```
+
+The likelihood of this attack is generally low
+but could be used in a targeted way
+against resources known to be important or expensive to distribute.
+
+This kind of attack can be mitigated on an individual basis
+by adding `.swiftpm/configuration` to a project's `.gitignore` file.
+
+### Escalation of privilege
+
+Even authentic packages from trusted creators can contain malicious code.
+
+Code analysis tools can help to some degree,
+as can system permissions and other OS-level security features.
+However, developers are ultimately responsible for the code they ship to users.
+
+## Impact on existing packages
+
+Current packages won't be affected by this change,
+as they'll continue to download dependencies directly through Git.
+
+## Alternatives considered
+
+### Use of alternative naming schemes
+
+Some package systems,
+including [RubyGems], [PyPI], and [CocoaPods]
+identify packages with bare names in a flat namespace
+(for example, `rails`, `pandas`, or `Alamofire`).
+Other systems,
+including [Maven],
+use [reverse domain name notation] to identify software components
+(for example, `com.squareup.okhttp3`).
+
+We considered these and other schemes for identifying packages,
+but they were rejected in favor of the scoped package identity
+described in this proposal.
+
+### Use of `tar` or other archive formats
+
+Swift Package Manager currently uses Zip archives for binary dependencies,
+which is reason enough to use it again here.
+
+Zip files are also a convenient format for package registries,
+because they support the access of individual files within an archive.
+This allows a registry to satisfy
+the package manifest endpoint
+(`GET /{scope}/{name}/{version}/Package.swift`)
+without storing anything separately from the archive used for the
+package archive endpoint
+(`GET /{scope}/{name}/{version}.zip`).
+
+We briefly considered `tar` as an archive format
+but concluded that its behavior of preserving symbolic links and executable bits
+served no useful purpose in the context of package management,
+and instead raised concerns about portability and security.
+
+### Inclusion of alternative source locations in package releases payload
+
+To maintain compatibility with existing, URL-based dependency declarations
+Swift Package Manager needs to reconcile source locations
+with their respective identifiers.
+For example,
+the declarations
+`.package(url: "https://github.com/mona/LinkedList", .exact("1.1.0"))` and
+`.package(id: "mona.LinkedList", .exact("1.1.0"))`,
+must be deemed equivalent
+to resolve a dependency graph that contains both of them.
+
+We considered including alternative source locations in the response body,
+but rejected that in favor of using link relations.
+
+[Web linking][RFC 8288] provides a standard way to
+describe the relationships between resources.
+Standard `canonical` and `alternative` [IANA link relations]
+convey precise semantics for
+the relationship between a package and its source repositories
+that are broadly useful beyond any individual client.
+
+### Addition of an `unarchive-source` subcommand
+
+This proposal adds an `archive-source` subcommand
+as a standard way for developers and registries
+to create source archives for packages.
+Having a canonical tool for creating source archives
+avoids any confusion when attempting to verify the integrity of
+Zip files sent from a registry
+with the source code for that package.
+
+We considered including a complementary `unarchive-source` subcommand
+but ultimately decided against it,
+the reason being that unarchiving a Zip archive
+is unambiguous and well-supported on most platforms.
+
+### Use of digital signatures
+
+[SE-0272] includes a discussion about
+the use of digital signatures for binary dependencies,
+concluding that they were unsuitable
+because of complexity around transitive dependencies.
+However, it's unclear what specific objections were raised in this proposal.
+We didn't see any inherent tension with the example provided,
+and no further explanation was given.
+
+Without understanding the context of this decision,
+we decided it was best to abide by their determination
+and instead consider adding this functionality in a future proposal.
+For the reasons outlined in the preceding Security section,
+we believe that digital signatures may offer additional guarantees
+of authenticity and non-repudiation beyond what's possible with checksums alone.
+
+## Future directions
+
+Defining a standard interface for package registries
+lays the groundwork for several useful features.
+
+### Package publishing
+
+A package registry is responsible for determining
+which package releases are made available to a consumer.
+This proposal sets no policies for how
+package releases are published to a registry.
+Nor does it specify how package scopes are registered or verified.
+
+Many package managers —
+including the ones mentioned above —
+and artifact repository services, such as
+[Docker Hub],
+[JFrog Artifactory],
+and [AWS CodeArtifact]
+follow what we describe as a *"push"* model of publication:
+When a package owner wants to releases a new version of their software,
+they produce a build locally and push the resulting artifact to a server.
+This model has the benefit of operational simplicity and flexibility.
+For example,
+maintainers have an opportunity to digitally sign artifacts
+before uploading them to the server.
+
+Alternatively,
+a system might incorporate build automation techniques like
+continuous integration (CI) and continuous delivery (CD)
+into what we describe as a *"pull"* model:
+When a package owner wants to release a new version of their software,
+their sole responsibility is to notify the package registry;
+the server does all the work of downloading the source code
+and packaging it up for distribution.
+This model can provide strong guarantees about
+reproducibility, quality assurance, and software traceability.
+
+We intend to work with industry stakeholders
+to develop standards for publishing Swift packages
+in an extension to the registry specification.
+
+### Package removal
+
+Removing a package from a registry
+can break other packages that depend on it,
+as demonstrated by the ["left-pad" incident][left-pad] in March 2016.
+We believe package registries can and should
+provide strong durability guarantees
+to ensure the health of the ecosystem.
+
+At the same time,
+there are valid reasons why a package release may be removed:
+
+* The package maintainer publishing a release by mistake
+* A security researcher disclosing a vulnerability for a release
+* The registry being compelled by law enforcement to remove a release
+
+It's unclear whether and to what extent package deletion policies
+should be informed by the registry specification itself.
+For now,
+a registry is free to exercise its own discretion
+about how to respond to out-of-band removal requests.
+
+We plan to consider these questions
+as part of the future extension to the specification
+described in the previous section.
+
+### Package dependency URL normalization
+
+As described in ["Package name collision resolution"](#package-name-collision-resolution)
+Swift Package Manager cannot build a project
+if two or more packages in the project
+are located by URLs with the same (case-insensitive) last path component.
+Swift Package Manager may improve support URL-based dependencies
+by normalizing package URLs to mitigate insignificant variations.
+For example,
+a package with an ["scp-style" URL][scp-url] like
+`git@github.com:mona/LinkedList.git`
+may be determined to be equivalent to a package with an HTTPS scheme like
+`https:///github.com/mona/LinkedList`.
+
+### Local offline cache
+
+Swift Package Manager could implement an [offline cache]
+that would allow it to work without network access.
+While this is technically possible today,
+a package registry makes for a simpler and more secure implementation
+than would otherwise be possible with Git repositories alone.
+
+### Binary framework distribution
+
+The registry specification could be amended to support the distribution of
+[XCFramework] bundles or [artifact archives][SE-0305].
+
+```http
+GET /github.com/mona/LinkedList/1.1.1.xcframework HTTP/1.1
+Host: packages.github.com
+Accept: application/vnd.swift.registry.v1+xcframework
+```
+
+Swift Package Manager could then use XCFramework archives as
+[binary dependencies][SE-0272]
+or as part of a future binary artifact distribution mechanism.
+
+```swift
+let package = Package(
+ name: "SomePackage",
+ /* ... */
+ targets: [
+ .binaryTarget(
+ name: "LinkedList",
+ url: "https://packages.github.com/github.com/mona/LinkedList/1.1.1.xcframework",
+ checksum: "ed04a550c2c7537f2a02ab44dd329f9e74f9f4d3e773eb883132e0aa51438b37"
+ ),
+ ]
+)
+```
+
+### Updates to package editor commands
+
+[Package editor commands][SE-0301]
+could be extended to add dependencies using scoped identifiers
+in addition to URLs.
+
+```console
+$ swift package add-dependency mona.LinkedList
+# Installed LinkedList 1.2.0
+```
+
+```diff
++ .package(id: "mona.LinkedList", .exact("1.2.0"))
+```
+
+### Package manifest dependency migration
+
+Swift Package Manager could add tooling
+to help package maintainers adopt registry-supported identifiers
+in their projects.
+
+```console
+$ swift package-registry migrate
+```
+
+```diff
+- .package(url: "https://github.com/mona/LinkedList", .exact("1.2.0"))
++ .package(id: "mona.LinkedList", .exact("1.2.0"))
+```
+
+### Security audits
+
+The response for listing package releases could be updated to include
+information about security advisories.
+
+```jsonc
+{
+ "releases": { /* ... */ },
+ "advisories": [{
+ "cve": "CVE-20XX-12345",
+ "cwe": "CWE-400",
+ "package": "mona.LinkedList",
+ "vulnerable_versions": "<=1.0.0",
+ "patched_versions": ">1.0.0",
+ "severity": "moderate",
+ "recommendation": "Update to version 1.0.1 or later.",
+ /* additional fields */
+ }]
+}
+```
+
+Swift Package Manager could communicate this information to users
+when installing or updating dependencies
+or as part of a new `swift package audit` subcommand.
+
+```console
+$ swift package audit
+┌───────────────┬────────────────────────────────────────────────┐
+│ High │ Regular Expression Denial of Service │
+├───────────────┼────────────────────────────────────────────────┤
+│ Package │ mona.RegEx │
+├───────────────┼────────────────────────────────────────────────┤
+│ Dependency of │ PatternMatcher │
+├───────────────┼────────────────────────────────────────────────┤
+│ Path │ SomePackage > PatternMatcher > RegEx │
+├───────────────┼────────────────────────────────────────────────┤
+│ More info │ https://example.com/advisories/526 │
+└───────────────┴────────────────────────────────────────────────┘
+
+Found 3 vulnerabilities (1 low, 1 moderate, 1 high) in 8 scanned packages.
+ Run `swift package audit fix` to fix 3 of them.
+```
+
+### Package search
+
+The package registry API could be extended to add a search endpoint
+to allow users to search for packages by name, keywords, or other criteria.
+This endpoint could be used by clients like Swift Package Manager.
+
+```console
+$ swift package search LinkedList
+LinkedList (github.com/mona/LinkedList) - One thing links to another.
+
+$ swift package search --author "Mona Lisa Octocat"
+LinkedList (github.com/mona/LinkedList) - One thing links to another.
+RegEx (github.com/mona/RegEx) - Expressions on the reg.
+```
+
+[AWS CodeArtifact]: https://aws.amazon.com/codeartifact/
+[BCP 13]: https://tools.ietf.org/html/rfc6838 "Media Type Specifications and Registration Procedures"
+[CDN]: https://en.wikipedia.org/wiki/Content_delivery_network "Content delivery network"
+[checksum database]: https://sum.golang.org "Go Module Mirror, Index, and Checksum Database"
+[CocoaPods]: https://cocoapods.org "A dependency manager for Swift and Objective-C Cocoa projects"
+[crates.io]: https://crates.io "crates.io: The Rust community’s crate registry"
+[Docker Hub]: https://hub.docker.com
+[GPG]: https://gnupg.org
+[homograph attacks]: https://en.wikipedia.org/wiki/IDN_homograph_attack
+[http header injection]: https://en.wikipedia.org/wiki/HTTP_header_injection
+[IANA link relations]: https://www.iana.org/assignments/link-relations/link-relations.xhtml "IANA Link Relation Types"
+[ICANN]: https://www.icann.org
+[JFrog Artifactory]: https://jfrog.com/artifactory/
+[JSON-LD]: https://w3c.github.io/json-ld-syntax/ "JSON-LD 1.1: A JSON-based Serialization for Linked Data"
+[left-pad]: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ "How one programmer broke the internet by deleting a tiny piece of code"
+[Maven]: https://maven.apache.org
+[npm]: https://www.npmjs.com "The npm Registry"
+[offline cache]: https://yarnpkg.com/features/offline-cache "Offline Cache | Yarn - Package Manager"
+[PyPI]: https://pypi.org "PyPI: The Python Package Index"
+[reverse domain name notation]: https://en.wikipedia.org/wiki/Reverse_domain_name_notation
+[RFC 2119]: https://tools.ietf.org/html/rfc2119 "Key words for use in RFCs to Indicate Requirement Levels"
+[RFC 3230]: https://tools.ietf.org/html/rfc5843 "Instance Digests in HTTP"
+[RFC 3492]: https://tools.ietf.org/html/rfc3492 "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)"
+[RFC 3986]: https://tools.ietf.org/html/rfc3986 "Uniform Resource Identifier (URI): Generic Syntax"
+[RFC 3987]: https://tools.ietf.org/html/rfc3987 "Internationalized Resource Identifiers (IRIs)"
+[RFC 5234]: https://tools.ietf.org/html/rfc5234 "Augmented BNF for Syntax Specifications: ABNF"
+[RFC 5843]: https://tools.ietf.org/html/rfc5843 "Additional Hash Algorithms for HTTP Instance Digests"
+[RFC 6249]: https://tools.ietf.org/html/rfc6249 "Metalink/HTTP: Mirrors and Hashes"
+[RFC 6570]: https://tools.ietf.org/html/rfc6570 "URI Template"
+[RFC 6749]: https://tools.ietf.org/html/rfc6749 "The OAuth 2.0 Authorization Framework"
+[RFC 7230]: https://tools.ietf.org/html/rfc7230 "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"
+[RFC 7231]: https://tools.ietf.org/html/rfc7231 "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+[RFC 7233]: https://tools.ietf.org/html/rfc7233 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests"
+[RFC 7234]: https://tools.ietf.org/html/rfc7234 "Hypertext Transfer Protocol (HTTP/1.1): Caching"
+[RFC 7807]: https://tools.ietf.org/html/rfc7807 "Problem Details for HTTP APIs"
+[RFC 8288]: https://tools.ietf.org/html/rfc8288 "Web Linking"
+[RFC 8446]: https://tools.ietf.org/html/rfc8446 "The Transport Layer Security (TLS) Protocol Version 1.3"
+[RubyGems]: https://rubygems.org "RubyGems: The Ruby community’s gem hosting service"
+[Schema.org]: https://schema.org/
+[scp-url]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol
+[SE-0219]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0219-package-manager-dependency-mirroring.md "Package Manager Dependency Mirroring"
+[SE-0272]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0272-swiftpm-binary-dependencies.md "Package Manager Binary Dependencies"
+[SE-0301]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0301-package-editing-commands.md "Package Editor Commands"
+[SE-0305]: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md "Package Manager Binary Target Improvements"
+[secret scanning]: https://docs.github.com/en/github/administering-a-repository/about-secret-scanning
+[SemVer]: https://semver.org/ "Semantic Versioning"
+[SoftwareSourceCode]: https://schema.org/SoftwareSourceCode
+[STRIDE]: https://en.wikipedia.org/wiki/STRIDE_(security) "STRIDE (security)"
+[thundering herd effect]: https://en.wikipedia.org/wiki/Thundering_herd_problem "Thundering herd problem"
+[TOFU]: https://en.wikipedia.org/wiki/Trust_on_first_use "Trust on First Use"
+[transparent log]: https://research.swtch.com/tlog
+[typosquatting]: https://en.wikipedia.org/wiki/Typosquatting
+[UTI]: https://en.wikipedia.org/wiki/Uniform_Type_Identifier
+[version-specific-manifest-selection]: https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#version-specific-manifest-selection "Swift Package Manager - Version-specific Manifest Selection"
+[version-specific-tag-selection]: https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#version-specific-tag-selection "Swift Package Manager - Version-specific Tag Selection"
+[XCFramework]: https://developer.apple.com/videos/play/wwdc2019/416/ "WWDC 2019 Session 416: Binary Frameworks in Swift"
+[xss]: https://en.wikipedia.org/wiki/Cross-site_scripting
+[Zip bomb]: https://en.wikipedia.org/wiki/Zip_bomb "Zip bomb"
+[Zip Slip]: https://snyk.io/research/zip-slip-vulnerability "Zip Slip Vulnerability"
diff --git a/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md b/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md
new file mode 100644
index 0000000000..cb28e27d6c
--- /dev/null
+++ b/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md
@@ -0,0 +1,762 @@
+# Extend Property Wrappers to Function and Closure Parameters
+
+* Proposal: [SE-0293](0293-extend-property-wrappers-to-function-and-closure-parameters.md)
+* Authors: [Holly Borla](https://github.com/hborla), [Filip Sakel](https://github.com/filip-sakel)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 5.5)**
+* Implementation: [apple/swift#34272](https://github.com/apple/swift/pull/34272), [apple/swift#36344](https://github.com/apple/swift/pull/36344)
+* Decision Notes: [Review #3](https://forums.swift.org/t/accepted-se-0293-extend-property-wrappers-to-function-and-closure-parameters/47030), [Review #2](https://forums.swift.org/t/returned-for-revision-2-se-0293-extend-property-wrappers-to-function-and-closure-parameters/44832), [Review #1](https://forums.swift.org/t/returned-for-revision-se-0293-extend-property-wrappers-to-function-and-closure-parameters/42953)
+* Previous versions: [Revision #2](https://github.com/swiftlang/swift-evolution/blob/bdf12b26d15d63ab7e58dab635a55ffeca841389/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md), [Revision #1](https://github.com/swiftlang/swift-evolution/blob/e5b2ce1fd6c1c2617a820a1e6f2b53a00e54fdce/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md)
+
+## Contents
+
++ [Introduction](#introduction)
++ [Motivation](#motivation)
+ - [Applying a common behavior via property wrapper](#applying-a-common-behavior-via-property-wrapper)
+ - [Arguments with auxiliary values via property wrapper projection](#arguments-with-auxiliary-values-via-property-wrapper-projection)
++ [Proposed solution](#proposed-solution)
++ [Detailed design](#detailed-design)
+ - [Passing a projected value argument](#passing-a-projected-value-argument)
+ - [Inference of API-level property wrappers](#inference-of-api-level-property-wrappers)
+ - [Implementation-detail property wrappers](#implementation-detail-property-wrappers)
+ - [Arguments in the property-wrapper attribute](#arguments-in-the-property-wrapper-attribute)
+ - [API-level property wrappers](#api-level-property-wrappers)
+ - [Function-body semantics](#function-body-semantics)
+ - [Call-site semantics](#call-site-semantics)
+ - [Unapplied function references](#unapplied-function-references)
+ - [Closures](#closures)
+ - [Overload resolution of backing property-wrapper initializer](#overload-resolution-of-backing-property-wrapper-initializer)
+ - [Restrictions on property-wrapper parameters](#restrictions-on-property-wrapper-parameters)
++ [Source compatibility](#source-compatibility)
++ [Effect on ABI stability](#effect-on-abi-stability)
++ [Effect on API resilience](#effect-on-api-resilience)
++ [Alternatives considered](#alternatives-considered)
+ - [Preserve property wrapper parameter attributes in the type system](#preserve-property-wrapper-parameter-attributes-in-the-type-system)
+ - [Only allow implementation-detail property wrappers on function parameters](#only-allow-implementation-detail-property-wrappers-on-function-parameters)
+ - [Pass a property-wrapper storage instance directly](#pass-a-property-wrapper-storage-instance-directly)
++ [Future directions](#future-directions)
+ - [The impact of formalizing separate property wrapper models](#the-impact-of-formalizing-separate-property-wrapper-models)
+ - [Explicit spelling for API-level property wrappers](#explicit-spelling-for-api-level-property-wrappers)
+ - [Generalized property-wrapper initialization from a projection](#generalized-property-wrapper-initialization-from-a-projection)
+ - [Static property-wrapper attribute arguments](#static-property-wrapper-attribute-arguments)
+ - [API property wrappers in protocol requirements](#api-property-wrappers-in-protocol-requirements)
+ - [Extend property wrappers to patterns](#extend-property-wrappers-to-patterns)
+ - [Support `inout` in wrapped function parameters](#support-inout-in-wrapped-function-parameters)
++ [Revisions](#revisions)
+ - [Changes from the second reviewed version](#changes-from-the-second-reviewed-version)
+ - [Changes from the first reviewed version](#changes-from-the-first-reviewed-version)
++ [Appendix](#appendix)
+ - [Mutability of composed `wrappedValue` accessors](#mutability-of-composed-wrappedValue-accessors)
++ [Acknowledgements](#acknowledgements)
+
+
+## Introduction
+
+Property Wrappers were [introduced in Swift 5.1](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0258-property-wrappers.md), 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.
+
+
+## Motivation
+
+Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to local variables and type properties, shattering the illusion that they helped realize in the first place when working with parameters.
+
+Property wrappers attached to parameters have a wide variety of use cases. We present a few examples here.
+
+### Applying a common behavior via property wrapper
+
+Property wrappers are often used as sugar for applying a common behavior to a value, such as asserting a precondition, transforming the value, or logging the value. Such behaviors are valuable to apply to function parameters. For example, using `Validation` from [`PropertyKit`](https://github.com/SvenTiigi/ValidatedPropertyKit), we can abstract various preconditions into a property wrapper:
+
+```swift
+@propertyWrapper
+struct Asserted {
+ init(
+ wrappedValue: Value,
+ validation: Validation,
+ ) { ... }
+
+ var wrappedValue: Value { ... }
+}
+```
+
+It would be useful to apply `@Asserted` to parameters to assert certain preconditions on argument values. For example, the following code asserts that the argument passed to the `quantity` parameter is greater than or equal to 1:
+
+```swift
+func buy(
+ @Asserted(.greaterOrEqual(1)) quantity: Int,
+ of product: Product,
+) { ... }
+```
+
+Similarly, one could write an `@Logged` property wrapper to be used as a light-weight debugging tool to see the arguments passed to a function each time that function is called:
+
+```swift
+@propertyWrapper
+struct Logged {
+ init(wrappedValue: Value) {
+ print(wrappedValue)
+ self.wrappedValue = wrappedValue
+ }
+
+ var wrappedValue: Value {
+ didSet {
+ print(wrappedValue)
+ }
+ }
+}
+
+// Every time `runAnimation` is called, the `duration` argument
+// will be logged by the property wrapper.
+func runAnimation(@Logged withDuration duration: Double) { ... }
+```
+
+### Arguments with auxiliary values via property wrapper projection
+
+Consider the following property wrapper, inspired by `@Traceable` from [David Piper's blog post](https://medium.com/better-programming/creating-a-history-with-property-wrappers-in-swift-5-1-4c0202060a7f), which tracks the history of a value:
+
+```swift
+struct History { ... }
+
+@propertyWrapper
+struct Traceable {
+ init(wrappedValue value: Value) { ... }
+ init(projectedValue: History) { ... }
+
+ private var history: History
+
+ var wrappedValue: Value {
+ get {
+ history.currentValue
+ }
+ set {
+ history.append(newValue)
+ }
+ }
+
+ var projectedValue: History {
+ history
+ }
+}
+```
+
+This property wrapper provides the history of the traced value via its projection, and it can be initialized with a value to be traced, or with an existing history of a traced value. Now consider the following model for a simple text editor that supports change tracking:
+
+```swift
+struct TextEditor {
+ @Traceable var dataSource: String
+}
+```
+
+Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized member-wise initializer. Because the `@Traceable` property wrapper supports initialization from a wrapped value via `init(wrappedValue:)`, the member-wise initializer for `TextEditor` will take in a `String`. However, the programmer may want to initialize `TextEditor` with a string value that already has a history. Today, this behavior can be achieved with overloads, which can greatly impact compile-time performance and impose boilerplate on the programmer. Another approach is to expose the `Traceable` type through the `TextEditor` initializer, which is unfortunate since the backing storage is meant to be implementation detail.
+
+## Proposed solution
+
+We propose to allow application of property wrappers on function and closure parameters, allowing the call-site to pass a wrapped value, or a projected value if appropriate, which will be used to automatically initialize the backing property wrapper. Within the body of the function, the function author can use the property-wrapper syntax for accessing the backing wrapper and the projected value.
+
+It's clear from a survey of the use cases for property wrappers on parameters that there are two kinds of property wrappers. The first kind of property wrapper is an abstraction of a common behavior on a value, such as logging, transforming, or caching a value. For these property wrappers, you use the wrapped value generally the same way as you would if the value did not have the wrapper attached, and the wrapper itself is implementation detail. Callers that provide the value to initialize the property wrapper will always pass an instance of the wrapped-value type.
+
+The second kind of property wrapper attaches additional semantics to the value being wrapped that are fundamental to understanding how the wrapped value can be used. These wrappers tend to attach auxiliary API through the wrapper's `projectedValue`, and many of these wrappers cannot be initialized from an instance of the wrapped-value type.
+
+The natural model for these two kinds of wrappers is different when applied to parameters, because the second model must allow the caller to pass a different type of argument. We propose to formalize the difference between 1) API-level property wrappers that have an external effect on the function, and 2) implementation-detail property wrappers. The compiler will determine whether a property wrapper must have an external effect on the function by analyzing the property wrapper's initializers.
+
+## Detailed design
+
+### Passing a projected value argument
+
+Property-wrapper projections are designed to allow property wrappers to provide a representation of the storage type that can be used outside of the context that owns the property-wrapper storage. Typically, projections either expose the backing property wrapper directly, or provide an instance of a separate type that vends more restricted access to the functionality of the property wrapper.
+
+When a property-wrapper has a projection, it's often necessary to use the projection alongside the wrapped value. In such cases, the projection is equal in importance to the wrapped value in the API of the wrapped property, which is reflected in the access control of synthesized projection properties. With respect to function parameters, it's equally important to support passing a projection.
+
+Property wrappers can enable passing a projected-value argument to a property-wrapped parameter by declaring `var projectedValue`, and implementing an `init(projectedValue:)` that meets the following requirements:
+
+- The first parameter of this initializer must be labeled `projectedValue` and have the same type as the `var projectedValue` property.
+- The initializer must have the same access level as the property-wrapper type.
+- The initializer must not be failable.
+- Any additional parameters to the initializer must have default arguments.
+
+This method of initialization is not mandatory for functions using supported wrapper types, and it can be disabled by providing arguments in the wrapper attribute, including empty attribute arguments: `func log(@Traceable() _ value: Value) { ... }`.
+
+### Inference of API-level property wrappers
+
+For a given property wrapper attached to a parameter, the compiler will infer whether that wrapper is part of the function signature based on whether the wrapper must have an external effect on the argument at the call-site. This proposal limits external argument effects to the case where the property wrapper allows the caller to pass an instance of the projected-value type, which means the property wrapper supports projected-value initialization via `init(projectedValue:)` and there are no arguments in the wrapper attribute.
+
+A property wrapper will only be inferred as API if `init(projectedValue:)` is declared directly in the nominal property wrapper type. This is to ensure that the same decision is always made regardless of which module the property wrapper is applied in. This is the same strategy that is used to determine whether a computed projection property with the `$` prefix should be synthesized when a property wrapper is applied, and whether a property wrapper supports initialization from a wrapped value. Once it is determined whether a property wrapper is API or implementation-detail, normal [overload resolution rules](#overload-resolution-of-backing-property-wrapper-initializer) will apply to the backing property wrapper initializer.
+
+### Implementation-detail property wrappers
+
+By default, property wrappers are implementation detail. Attaching an implementation-detail property wrapper attribute to a parameter will synthesize the following local variables in the function body:
+
+* A local `let`-constant representing the backing storage will be synthesized with the name of the parameter prefixed with an underscore. The backing storage is initialized by passing the parameter to `init(wrappedValue:)`.
+* A local computed variable representing the `wrappedValue` of the innermost property wrapper will be synthesized with the same name as the original, unprefixed parameter name. If the innermost `wrappedValue` defines a setter, a setter will be synthesized for the local property if the [mutability of the composed setter](#mutability-of-composed-wrappedValue-accessors) is `nonmutating`.
+* If the outermost property wrapper defines a `projectedValue` property with a `nonmutating` getter, a local computed variable representing the outermost `projectedValue` will be synthesized and named per the original parameter name prefixed with a dollar sign (`$`). If the outermost `projectedValue` defines a setter, a setter for the local computed variable will be synthesized if the `projectedValue` setter is `nonmutating`.
+
+
+Consider the following code, which attaches the `@Logged` property wrapper to a parameter.
+
+```swift
+func insert(@Logged text: String) { ... }
+```
+
+The above code is sugar for:
+
+```swift
+func insert(text: String) {
+ let _text: Logged = Logged(wrappedValue: text)
+
+ var text: String { _text.wrappedValue }
+}
+```
+
+Note that the backing storage is a let-constant, and the local `text` property does not have a setter.
+
+> **Rationale**: The ability to mutate a wrapped parameter would likely confuse users into thinking that the mutations they make are observable by the caller; that's not the case. There was a similar feature in Swift which was removed in [SE-0003](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0003-remove-var-parameters.md).
+
+Implementation-detail property wrappers on parameters must support initialization from a wrapped value, and the parameter type must be equal to the wrapped value type of the wrapper. Because the backing storage is initialized locally, implementation-detail property wrappers have no external effect on the function. A function that uses implementation-detail property wrappers on parameters can fulfill protocol requirements that use the wrapped-value type:
+
+```swift
+protocol P {
+ func requirement(value: Int)
+}
+
+struct S: P {
+ func requirement(@Logged value: Int) {
+ ...
+ }
+}
+```
+
+#### Arguments in the property-wrapper attribute
+
+Property-wrapper attributes with arguments applied to parameters are always implementation-detail property wrappers, even if the property wrapper supports initialization from a projected value.
+
+> **Rationale**: Arguments in the wrapper attribute only apply to `init(wrappedValue:)`. To ensure that these arguments never change, the property wrapper must always be initialized via `init(wrappedValue:)` and pass the additional attribute arguments. Because the caller can only pass a wrapped value, there is no reason for the property wrapper to affect the function externally.
+
+Because property wrappers with attribute arguments are always implementation-detail, the arguments will always be evaluated in the function body.
+
+### API-level property wrappers
+
+Property wrappers that declare an `init(projectedValue:)` initializer are inferred to be API-level wrappers. These wrappers become part of the function signature, and the property wrapper is initialized at the call-site of the function.
+
+#### Function-body semantics
+
+Attaching an API-level property wrapper to a parameter makes that parameter a computed variable local to the function body, and changes the parameter type to the backing wrapper type. The type of the parameter is only observable in compiled code; [unapplied references to functions with property-wrapped parameters](#unapplied-function-references) will not use the backing-wrapper type.
+
+The transformation of functions with a property-wrapped parameter will be performed as such:
+
+* The argument label will remain unchanged.
+* The parameter name will be prefixed with an underscore.
+* The type of the parameter will be the backing property-wrapper type.
+* A local computed variable representing the `wrappedValue` of the innermost property wrapper will be synthesized with the same name as the original, unprefixed parameter name. If the innermost `wrappedValue` defines a setter, a setter will be synthesized for the local property if the [mutability of the composed setter](#mutability-of-composed-wrappedValue-accessors) is `nonmutating`.
+* If the outermost property wrapper defines a `projectedValue` property with a `nonmutating` getter, a local computed variable representing the outermost `projectedValue` will be synthesized and named per the original parameter name prefixed with a dollar sign (`$`). If the outermost `projectedValue` defines a setter, a setter for the local computed variable will be synthesized if the `projectedValue` setter is `nonmutating`.
+
+Consider the following function which has a parameter with the `@Traceable` property wrapper attached:
+
+```swift
+func copy(@Traceable text: String) { ... }
+```
+
+The compiler will synthesize computed `text` and `$text` variables in the body of `copy(text:)`:
+
+```swift
+func copy(text _text: Traceable) {
+ var text: String {
+ get { _text.wrappedValue }
+ }
+
+ var $text: History {
+ get { _text.projectedValue }
+ }
+
+ ...
+}
+```
+
+#### Call-site semantics
+
+When passing an argument to a parameter with an API-level property wrapper, the compiler will wrap the argument in a call to the appropriate initializer depending on the argument label. When using the original argument label (or no argument label), the compiler will wrap the argument in a call to `init(wrappedValue:)`. When using the argument label prefixed with `$` (or `$_` in the case of no argument label), the compiler will wrap the argument in a call to `init(projectedValue:)`.
+
+Consider the `@Traceable` property wrapper that implements both `init(wrappedValue:)` and `init(projectedValue:)`:
+
+```swift
+struct History { ... }
+
+@propertyWrapper
+struct Traceable {
+ init(wrappedValue value: Value)
+ init(projectedValue: History)
+
+ var wrappedValue: Value
+ var projectedValue: History
+}
+```
+
+A function with an `@Traceable` parameter can be called with either a wrapped value or a projected value:
+
+```swift
+func log(@Traceable value: Value) { ... }
+
+let history: History = ...
+
+log(value: 10)
+log($value: history)
+```
+
+The compiler will inject a call to the appropriate property-wrapper initializer into each call to `log` based on the argument label, so the above code is transformed to:
+
+```swift
+log(value: Traceable(wrappedValue: 10))
+log(value: Traceable(projectedValue: history))
+```
+
+Wrapped parameters with no argument label can still be passed a projection using the syntax `$_:`, as shown in the following example:
+
+```swift
+func log(@Traceable _ value: Value) { ... }
+
+let history: History = ...
+
+log(10)
+log(_: 10)
+log($_: history)
+```
+
+For composed property wrappers, initialization of the backing wrapper via wrapped value will contain a call to `init(wrappedValue:)` for each property-wrapper attribute in the composition chain. However, initialization via projected value will only contain one call to `init(projectedValue:)` for the outermost wrapper attribute, because property wrapper projections are not composed. For example:
+
+```swift
+func log(@Traceable @Traceable text: String) { ... }
+
+let history: History> = ...
+
+log(text: "Hello!")
+log($text: history)
+```
+
+The above calls to `log` are transformed to:
+
+```swift
+log(text: Traceable(wrappedValue: Traceable(wrappedValue: "Hello!"))
+log(text: Traceable(projectedValue: history))
+```
+
+This transformation at the call-site only applies when calling the function directly using the declaration name.
+
+#### Unapplied function references
+
+By default, unapplied references to functions that accept property-wrapped parameters use the wrapped-value type in the parameter list.
+
+Consider the `log` function from above, which uses the `@Traceable` property wrapper:
+
+```swift
+func log(@Traceable value: Value) { ... }
+```
+
+The type of `log` is `(Value) -> Void`. These semantics can be observed when working with an unapplied reference to `log`:
+
+```swift
+let logReference: (Int) -> Void = log
+logReference(10)
+
+let labeledLogReference: (Int) -> Void = log(value:)
+labeledLogReference(10)
+```
+
+The compiler will generate a thunk when referencing `log` to take in the wrapped-value type and initialize the backing property wrapper. Both references to `log` in the above example are transformed to:
+
+```swift
+{ log(value: Traceable(wrappedValue: $0) }
+```
+
+The type of an unapplied function reference can be changed to instead take in the projected-value type using `$` in front of the argument label. Since `Traceable` implements `init(projectedValue:)`, the `log` function can be referenced in a way that takes in `History` by using `$` in front of `value`:
+
+```swift
+let history: History = ...
+let logReference: (History) -> Void = log($value:)
+logReference(history)
+```
+
+If a wrapped parameter omits an argument label, the function can be referenced to take in the projected-value type using `$_`:
+
+```swift
+func log(@Traceable _ value: Value) { ... }
+
+let history: History = ...
+let logReference: (History) -> Void = log($_:)
+logReference(history)
+```
+
+### Closures
+
+Property wrappers can be attached to closure parameter declarations in the closure expression. Property-wrapper attributes are not propagated through the type system, so a given closure can only be passed either a wrapped value or a projected value. Because of this, closures parameters do not distinguish between implementation-detail and API property wrappers; all property wrappers will be initialized from the appropriate argument in the order they appear in the parameter list before the closure body is executed.
+
+The `log` function from the previous section can be implemented as a closure that takes in the wrapped-value type:
+
+```swift
+let log: (Int) -> Void = { (@Traceable value) in
+ ...
+}
+```
+
+The closure can be written to instead take in the projected-value type by using the `$` prefix in the parameter name:
+
+```swift
+let log: (History) -> Void = { (@Traceable $value) in
+ ...
+}
+```
+
+For closures that take in a projected value, the property-wrapper attribute is not necessary if the backing property wrapper and the projected value have the same type, such as the [`@Binding`](https://developer.apple.com/documentation/swiftui/binding) property wrapper from SwiftUI. If `Binding` implemented `init(projectedValue:)`, it could be used as a property-wrapper attribute on closure parameters without explicitly writing the attribute:
+
+```swift
+let useBinding: (Binding) -> Void = { $value in
+ ...
+}
+```
+
+Since property-wrapper projections are not composed, `$` closure parameters can only have one property-wrapper attribute.
+
+### Overload resolution of backing property-wrapper initializer
+
+For both implementation-detail and API property wrappers, the type of the wrapped parameter (not the argument) is used for overload resolution of `init(wrappedValue:)` and `init(projectedValue:)`. For example:
+
+```swift
+@propertyWrapper
+struct Wrapper {
+ init(wrappedValue: Value) { ... }
+
+ init(wrappedValue: Value) where Value: Collection { ... }
+}
+
+func generic(@Wrapper value: T) { ... }
+```
+
+The above property wrapper defines overloads of `init(wrappedValue:)` with different generic constraints. When the property wrapper is applied to the function parameter `value` of generic parameter type `T`, overload resolution will choose which `init(wrappedValue:)` to call based on the constraints on `T`. `T` is unconstrained, so the unconstrained `init(wrappedValue:)` will always be called:
+
+```swift
+// Both of the following calls use the unconstrained 'init(wrappedValue:)'
+generic(value: 10)
+generic(value: [1, 2, 3])
+```
+
+The function `generic` could be overloaded where `T: Collection` to allow the constrained `init(wrappedValue:)` to be called:
+
+```swift
+func generic(@Wrapper value: T) { ... }
+func generic(@Wrapper value: T) { ... }
+
+generic(value: 10) // calls the unconstrained init(wrappedValue:)
+generic(value: [1, 2, 3]) // calls init(wrappedValue:) where Value: Collection
+```
+
+### Restrictions on property-wrapper parameters
+
+Property wrappers attached to parameters must support either or both of `init(wrappedValue:)` and `init(projectedValue:)`.
+
+> **Rationale**: If a property wrapper does not support either of these initializers, the compiler does not know how to automatically initialize the property wrapper given an argument.
+
+The composed mutability of the innermost `wrappedValue` getter must be `nonmutating`.
+
+> **Rationale**: If the composed `wrappedValue` getter is `mutating`, then the local computed property for a property-wrapper parameter must mutate the backing wrapper, which is immutable.
+
+Property-wrapper parameters cannot have an `@autoclosure` type.
+
+> **Rationale**: A wrapped value cannot have an `@autoclosure` type. If `init(wrappedValue:)` needs to accept an `@autoclosure`, a warning will be emitted with a fix-it prompting the user to use a regular `@autoclosure` parameter and a local property wrapper instead.
+
+API property-wrapper parameters cannot also have an attached result builder attribute.
+
+> **Rationale**: Result-builder attributes can be applied to the parameters in `init(wrappedValue:)` and `init(projectedValue:)`. If there is a result builder attached to a property-wrapper parameter that already has a result builder in `init(wrappedValue:)`, it's unclear which result builder should be applied.
+
+Non-instance methods cannot use property wrappers that require the [enclosing `self` subscript](0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type).
+
+> **Rationale**: Non-instance methods do not have an enclosing `self` instance, which is required for the local computed property that represents `wrappedValue`.
+
+API property wrapper attributes can only be applied to parameters in overridden functions or protocol witnesses if the superclass function or protocol requirement, respectively, has the same property wrapper attributes.
+
+> **Rationale**: This restriction ensures that the call-site transformation is always the same for families of dynamically dispatched functions.
+
+API property wrappers must match the access level of the enclosing function.
+
+> **Rationale**: These property wrappers have an external effect on the argument at the call-site, so they must be accessible to all callers.
+
+## Source compatibility
+
+This is an additive change with no impact on source compatibility.
+
+## Effect on ABI stability
+
+This is an additive change with no impact on the existing ABI.
+
+## Effect on API resilience
+
+Implementation-detail property wrappers have no impact on API resilience. These property wrappers will not be preserved in the generated Swift interface for the module; they are entirely implementation details.
+
+API-level property wrappers applied to function parameters are part of the API and ABI of that function. A property wrapper applied to a function parameter changes the type of that parameter, which is reflected in the ABI; it also changes the way that function callers are compiled to pass an argument of that type. Thus, adding or removing a property wrapper on an ABI-public function parameter is not a resilient change.
+
+Property wrappers changing between implementation-detail and API-level is not a resilient change. Consider a property wrapper that is implementation-detail when applied to a parameter. Adding an `init(projectedValue:)` initializer to this property wrapper is a source-breaking change for clients that use this property wrapper in a function that is a protocol witness, and it is an ABI breaking change for any code that uses this property wrapper on a parameter. We expect this case to be very rare, and clients can work around the source and ABI break by either adding an argument to the wrapper attribute or using a local wrapped variable instead.
+
+## Alternatives considered
+
+### Preserve property-wrapper parameter attributes in the type system
+
+One approach to achieving the expected semantics for higher-order functions with property wrappers in the parameter list is to preserve property-wrapper attributes in parameter types. While this is feasible for plain property-wrapper attributes, it is not feasible in the case where the property-wrapper attribute has attribute arguments, because type equality cannot be dependent on expression equivalence.
+
+### Only allow implementation-detail property wrappers on function parameters
+
+Only allowing implementation-detail property wrappers on function parameters would eliminate the need for the API-level versus implementation-detail distinction for functions, because the property wrapper would never have an external effect on the argument. However, allowing property wrappers to have an external effect on the wrapped declaration is part of what makes the feature so powerful and applicable to a wide variety of use cases. One fairly common class of property wrappers are those which provide an abstracted reference to a value, such as the [`Ref` / `Box` example](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0258-property-wrappers.md#ref--box) from the SE-0258 proposal, and [`Binding`](https://developer.apple.com/documentation/swiftui/binding) from SwiftUI. It's common to pass these property wrappers around as projections, and there isn't currently a nice way to achieve the property wrapper sugar in a function body that uses such a property wrapper. The best way to achieve this currently is to use a local property wrapper and initialize the backing storage directly, e.g.
+
+```swift
+func useReference(reference: Ref) {
+ @Ref var value: Int
+ _value = reference
+}
+```
+
+Furthermore, property wrappers can already have an external effect on the wrapped declaration. For example, the compiler may change the type of the accessors of the wrapped declaration based on the mutability of the property wrapper's `wrappedValue` accessors, and the synthesized member-wise initializer of a type containing wrapped properties can change based on which initializers the property wrapper provides. Formalizing the distinction can only help the compiler provide the programmer with more tools to understand code that uses such property wrappers.
+
+### Pass a property-wrapper storage instance directly
+
+A previous revision of this proposal supported passing a property-wrapper storage instance to a function with a wrapped parameter directly because the function type was in terms of the property-wrapper type. A big point of criticism during the first review was that the backing storage type should be an artifact of the function implementation, and not exposed to function callers through the type system.
+
+Exposing the property-wrapper storage type through the type system has the following implications, summarized by [Frederick Kellison-Linn](https://forums.swift.org/u/jumhyn):
+
+* The addition/removal of a property-wrapper attribute on a function parameter is a source-breaking change for any code that references or curries the function.
+* It prohibits the use of initializer arguments in the wrapper attribute. There's no point in declaring a wrapper as `@Asserted(.greaterOrEqual(1))` if any client can simply pass an `Asserted` instance with a completely different validation.
+* It removes API control from both the property wrapper author and the author of the wrapped-argument function.
+
+Keeping the property-wrapper storage type private is consistent with how property wrappers work today. Unless a property wrapper projects its storage type via `projectedValue`, the storage type itself is meant to be a private implementation detail inaccessible to API clients.
+
+## Future directions
+
+### The impact of formalizing separate property wrapper models
+
+The design of this property wrapper extension includes a formalized distinction between property wrappers that are implementation detail and property wrappers that are API. These two kinds of wrappers will need to be modeled differently in certain places in the language. This section explores the impact that introducing two separate models for property wrappers will have on the language and the future design space for property wrappers.
+
+The property wrapper model inside the declaration context of the wrapped property will remain the same between these two kinds of property wrappers. Whether the property wrapper is API or implementation detail, the auxiliary declaration model is fundamental to programmers' understanding of how property wrappers work and how to use them, and this model should not be changed in any future enhancement to the property wrapper feature. Property wrappers are and will always be syntactic sugar for code that the programmer can write manually using exactly the strategy that the compiler uses — auxiliary variables and custom accessors on the wrapped property. Any enhancements to property wrappers that add capabilities to the auxiliary declarations, such as access to the enclosing `self` instance or delegating to an existing stored property, will not be impacted by the API versus implementation detail distinction.
+
+The distinction of API versus implementation detail _will_ have an impact outside of the enclosing context of the wrapped declaration. Conceptually, the API versus implementation-detail distinction should only impact the parts of the language where an abstraction that contains a property wrapper attribute is used.
+
+Across module boundaries, implementation-detail property wrappers become invisible, because these wrappers are purely a detail of how the module is implemented. Clients have no knowledge of these wrappers, so property wrapper attributes that appear in the module must be API property wrappers.
+
+The modeling difference between implementation-detail and API property wrappers is only observable when both are used within the same module, and the difference is mainly observable in the language restrictions on the use of API versus implementation-detail wrappers. These two models are designed such that nearly all observable semantics of property wrapper application do not differ based on where the wrapper is applied. The only observable semantic difference that the proposal authors can think of is evaluation order among property wrapper initialization and other arguments that are passed to the API, and the proposal authors believe it is extremely unlikely that this evaluation order will have any impact on the functionality of the code. For evaluation order to have a functional impact, both the property wrapper initializer _and_ another function argument would both need to call into a separate function that has some side effect. For example:
+
+```swift
+func hasSideEffect() -> Int {
+ struct S {
+ static var state = 0
+ }
+
+ S.state += 1
+ return S.state
+}
+
+@propertyWrapper
+struct Wrapper {
+ var wrappedValue: Int
+
+ init(wrappedValue: Int) {
+ self.wrappedValue = wrappedValue + hasSideEffect()
+ }
+}
+
+func demonstrateEvaluationOrder(@Wrapper arg1: Int, arg2: Int) {
+ print(arg1, arg2)
+}
+
+demonstrateEvaluationOrder(arg1: 1, arg2: hasSideEffect())
+```
+
+If the property wrapper initializer is evaluated in the caller, the output of this code is `2, 2`. If the property wrapper initializer is evaluated in the callee, the output of the code is `3, 1`.
+
+The proposal authors believe that these two kinds of property wrappers already exist, and formalizing the distinction is a first step in enhancing programmers' understanding of such a complex feature. Property wrappers are very flexible to cover a wide variety of use cases. Formalizing the two broad categories of use cases opens up many interesting possibilities for the language and compiler to enhance library documentation when API wrappers are used, provide better guidance to programmers, and even allow library authors to augment the guidance given to programmers on invalid code through, for example, library-defined diagnostic notes.
+
+### Explicit spelling for API-level property wrappers
+
+The scope of what is considered an API-level property wrapper is very limited in this proposal, and the external effect of an API-level property wrapper may be useful for wrappers that don't fit the current definition. The `@propertyWrapper` attribute could have an explicit `apiLevel` option that allows library authors to define whether the property wrapper has an external effect on the wrapped declaration:
+
+```swift
+@propertyWrapper(apiLevel)
+struct Asserted {
+ init(
+ wrappedValue: Value,
+ _ assertion: (Value) -> Bool,
+ file: StaticString = #file,
+ line: UInt = #line
+ ) { ... }
+}
+```
+
+### Generalized property-wrapper initialization from a projection
+
+This proposal adds `init(projectedValue:)` as a new property-wrapper initialization mechanism for function parameters. This mechanism could also be used to support initialization from a projected value for properties and local variables via [definite initialization](https://en.wikipedia.org/wiki/Definite_assignment_analysis):
+
+```swift
+struct TextEditor {
+ @Traceable var dataSource: String
+
+ init(history: History) {
+ // treated as _dataSource = Traceable(projectedValue: history)
+ $dataSource = history
+ }
+}
+```
+
+### Static property-wrapper attribute arguments
+
+This proposal does not allow API-level property wrappers to have arguments in the wrapper attribute to ensure that these arguments remain the same across the different initialization mechanisms. Instead of passing these arguments to the property-wrapper initializer, property wrappers could opt into storing these arguments in per-wrapped-declaration static storage that is shared across property-wrapper instances. Consider the following example, inspired by [ValidatedPropertyKit](https://github.com/SvenTiigi/ValidatedPropertyKit):
+
+```swift
+@propertyWrapper(sharedInfo: Validation)
+struct Asserted {
+ struct Validation {
+ private let predicate: (Value) -> Bool
+
+ init(predicate: @escaping (Value) -> Bool) {
+ self.predicate = predicate
+ }
+
+ init(_ validation: Validation) {
+ self.predicate = validation.predicate
+ }
+
+ static func greaterOrEqual(_ value: Value) -> Self {
+ .init { $0 >= value }
+ }
+ }
+
+ init(wrappedValue: Value) { ... }
+
+ // This is the 'wrappedValue'
+ subscript(sharedInfo: Validation) -> Value {
+ get { ... }
+ set { ... }
+ }
+}
+```
+
+When `Asserted` is applied as a property wrapper, the arguments to the wrapper attribute become arguments to the `Validation` initializer, which would have static storage that is shared across each instance of the `Asserted` property wrapper in the following struct:
+
+```swift
+struct S {
+ @Asserted(.greaterOrEqual(1)) var value: Int = 10
+}
+
+// translated to -->
+
+struct S {
+ private static let _value$sharedInfo: Asserted.Validation
+ = .init(.greaterOrEqual(1))
+
+ private var _value: Asserted
+ = .init(wrappedValue: 10)
+
+ var value: Int {
+ get { _value[sharedInfo: _value$sharedInfo] }
+ set { _value[sharedInfo: _value$sharedInfo] = newValue }
+ }
+}
+```
+
+This static storage mechanism would eliminate a lot of unnecessary storage in property wrapper instances. It would also allow API property wrappers on parameters to have attribute arguments, because those arguments are guaranteed to never change regardless of how the property wrapper is initialized.
+
+### API property wrappers in protocol requirements
+
+Protocol requirements that include property wrappers was [pitched](https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953) a while ago, but there was a lot of disagreement about whether property wrappers are implementation detail or API. With this distinction formalized, we could allow only API-level property wrappers in protocol requirements.
+
+### Extend property wrappers to patterns
+
+Passing a property-wrapper storage instance directly to a property-wrapped closure parameter was supported in first revision. One suggestion from the core team was to imagine this functionality as an orthogonal feature to allow pattern matching to "unwrap" property wrappers. Though this proposal revised the design of closures to match the behavior of unapplied function references, extending property wrappers to all patterns is still a viable future direction.
+
+Enabling the application of property wrappers in value-binding patterns would facilitate using the intuitive property-wrapper syntax in more language constructs, as shown below:
+
+```swift
+enum Review {
+ case revised(Traceable)
+ case original(String)
+}
+
+switch Review(fromUser: "swiftUser5") {
+case .revised(@Traceable let reviewText),
+ .original(let reviewText):
+ // do something with 'reviewText'
+}
+```
+
+### Support `inout` in wrapped function parameters
+
+This proposal doesn't currently support marking property-wrapped function parameters `inout`. We deemed that this functionality would be better tackled by another proposal, due to its implementation complexity. Nonetheless, this would be useful for mutating a wrapped parameter with the changes written back to the argument that was passed.
+
+## Revisions
+
+### Changes from the second reviewed version
+
+* The distinction between API wrappers and implementation-detail wrappers is formalized, and determined by the compiler based on whether the property wrapper type allows the call-site to pass a different type of argument.
+* Implementation-detail property wrappers on parameters use callee-side application of the property wrapper, and have no external effect on the function.
+* API property wrappers on parameters use caller-side application of the property wrapper, and are part of the function signature.
+* Overload resolution for property wrapper initializers will always be done at the property wrapper declaration.
+
+### Changes from the first reviewed version
+
+* Passing a projected value using the `$` calling syntax is supported via `init(projectedValue:)`.
+* The type of the unapplied function reference uses the wrapped-value type by default. Referencing the function using the projected-value type is supported by writing `$` in front of the argument label, or by writing `$_` if there is no argument label.
+* Closures with property-wrapper parameters have the same semantics as unapplied function references.
+* Additional arguments in the wrapper attribute are supported, and these arguments have the same evaluation semantics as default function arguments.
+
+## Appendix
+
+#### Mutability of composed `wrappedValue` accessors
+
+The algorithm is computing the mutability of the synthesized accessors for a wrapped parameter (or property) with _N_ attached property wrapper attributes. Attribute 1 is the outermost attribute, and attribute _N_ is the innermost. The accessor mutability is the same as the mutability of the _N_ th .wrappedValue access, e.g. _param.wrappedValue1.wrappedValue2. [...] .wrappedValueN
+
+The mutability of the _N_ th access is defined as follows:
+
+* If _N = 1_, the mutability of the access is the same as the mutability of the wrappedValue accessor in the 1st property wrapper.
+Otherwise:
+ * If the wrappedValue accessor in the _N_ th property wrapper is nonmutating, then the _N_ th access has the same mutability as the _N - 1_ th get access.
+ * If the wrappedValue accessor in the _N_ th property wrapper is mutating, then the _N_ th access is mutating if the _N - 1_ th get or set access is mutating.
+
+**Example**: Consider the following `Reference` property wrapper, which is composed with `Logged` and used on a function parameter:
+
+```swift
+@propertyWrapper
+struct Reference {
+ var wrappedValue: Value {
+ get { ... }
+ nonmutating set { ... }
+ }
+ var projectedValue: Reference {
+ self
+ }
+}
+
+func useReference(@Reference @Logged reference: String) {
+ ...
+}
+```
+
+In the above example, the function `useReference` is equivalent to:
+
+```swift
+func useReference(reference _reference: Reference>) {
+ var reference: String {
+ get {
+ _reference.wrappedValue.wrappedValue
+ }
+ set {
+ _reference.wrappedValue.wrappedValue = newValue
+ }
+ }
+
+ var $reference: Reference> {
+ get {
+ _reference.projectedValue
+ }
+ }
+
+ ...
+}
+```
+
+Since both the getter and setter of `Reference.wrappedValue` are `nonmutating`, a setter can be synthesized for `var reference`, even though `Logged.wrappedValue` has a `mutating` setter. `Reference` also defines a `projectedValue` property, so a local computed property called `$reference` is synthesized in the function body, but it does _not_ have a setter, because `Reference.projectedValue` only defines a getter.
+
+## Acknowledgements
+
+This proposal was greatly improved as a direct result of feedback from the community. [Doug Gregor](https://forums.swift.org/u/douglas_gregor) and [Dave Abrahams](https://forums.swift.org/u/dabrahams) surfaced more use cases for property-wrapper parameters. [Frederick Kellison-Linn](https://forums.swift.org/u/jumhyn) proposed the idea to change the behavior of unapplied function references based on argument labels, and provided [ample justification](#passing-a-property-wrapper-storage-instance-directly) for why the semantics in the first revision were unintuitive. [Lantua](https://forums.swift.org/u/lantua) pushed for the behavior of closures to be consistent with that of functions, and proposed the idea to use `$` on closure parameters in cases where the wrapper attribute is unnecessary. Finally, ideas from [Jens Jakob Jensen](https://forums.swift.org/u/jjj) and [John McCall](https://forums.swift.org/u/john_mccall) were combined to produce the 'inference of external property wrapper' design in its current form.
+
+Many others participated throughout the several pitches and reviews. This feature would not be where it is today without the thoughtful contributions from folks across our community.
diff --git a/proposals/0294-package-executable-targets.md b/proposals/0294-package-executable-targets.md
new file mode 100644
index 0000000000..31aa5593b7
--- /dev/null
+++ b/proposals/0294-package-executable-targets.md
@@ -0,0 +1,200 @@
+# Declaring executable targets in Package Manifests
+
+* Proposal: [SE-0294](0294-package-executable-targets.md)
+* Authors: [Anders Bertelrud](https://github.com/abertelrud)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Status: **Implemented (Swift 5.4)**
+* Implementation: [apple/swift-package-manager#3045](https://github.com/apple/swift-package-manager/pull/3045)
+* Bugs: [SR-13924](https://bugs.swift.org/browse/SR-13924)
+* Pitch: [Forum Discussion](https://forums.swift.org/t/pitch-ability-to-declare-executable-targets-in-swiftpm-manifests-to-support-main/)
+* Review: [Forum Discussion](https://forums.swift.org/t/se-0294-declaring-executable-targets-in-package-manifests/)
+
+## Introduction
+
+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.
+
+Letting package authors declare targets as executable allows the use of `@main`
+in Swift package targets. It also allows for better diagnostics, since the
+purpose of the target is unambiguous even if source files are moved or renamed.
+
+## Motivation
+
+The Swift Package Manager doesn’t currently provide a way for a package manifest
+to declare that a target provides the main module for an executable. Instead,
+SwiftPM infers this by looking for a compilable source file with a base name of
+`main` at the top level of the target directory.
+
+It is important to know unambiguously whether or not a target is intended to be
+executable, because it affects the flags that are passed to the compiler at
+build time. It also affects the quality of diagnostics, such as detecting
+product declarations that mistakenly include more or less than a single
+executable target in an executable product.
+
+Relying on specially named source files also doesn’t work when using `@main` to
+specify the entry point of an executable. In addition, there are ergonomic
+problems with using specially named source files (e.g.
+[SR-1379](https://bugs.swift.org/browse/SR-1379)) that would be addressed by
+being able to explicitly declare a target as being executable in the manifest.
+
+## Proposed solution
+
+The most straightforward approach is to allow a target to be marked as
+executable in the manifest. This could take the form of either a parameter to
+the existing `target` type, or a new target type.
+
+There is already an established pattern of using the type itself to denote the
+kind of target being declared (e.g. `testTarget` as a specialization of
+`target`), so this proposal suggests adding a new `executableTarget` type for
+this purpose.
+
+Using a separate target type in the manifest would also support any future
+differences in parameters between an executable target and a library target.
+It would also be easier to read in a package manifest that includes a long
+list of target declarations.
+
+## Detailed design
+
+The `PackageDescription` API is updated to add an `executableTarget` function,
+currently having the same parameters as the `target` function:
+
+```swift
+/// Creates an executable target.
+///
+/// An executable target can contain either Swift or C-family source files, but not both. It contains code that
+/// is built as an executable module that can be used as the main target of an executable product. The target
+/// is expected to either have a source file named `main.swift`, `main.m`, `main.c`, or `main.cpp`, or a source
+/// file that contains the `@main` keyword.
+///
+/// - Parameters:
+/// - name: The name of the target.
+/// - dependencies: The dependencies of the target. A dependency can be another target in the package or a product from a package dependency.
+/// - path: The custom path for the target. By default, the Swift Package Manager requires a target's sources to reside at predefined search paths;
+/// for example, `[PackageRoot]/Sources/[TargetName]`.
+/// Don't escape the package root; for example, values like `../Foo` or `/Foo` are invalid.
+/// - exclude: A list of paths to files or directories that the Swift Package Manager shouldn't consider to be source or resource files.
+/// A path is relative to the target's directory.
+/// This parameter has precedence over the `sources` parameter.
+/// - sources: An explicit list of source files. If you provide a path to a directory,
+/// the Swift Package Manager searches for valid source files recursively.
+/// - resources: An explicit list of resources files.
+/// - publicHeadersPath: The directory containing public headers of a C-family library target.
+/// - cSettings: The C settings for this target.
+/// - cxxSettings: The C++ settings for this target.
+/// - swiftSettings: The Swift settings for this target.
+/// - linkerSettings: The linker settings for this target.
+@available(_PackageDescription, introduced: 999.0)
+public static func executableTarget(
+ name: String,
+ dependencies: [Dependency] = [],
+ path: String? = nil,
+ exclude: [String] = [],
+ sources: [String]? = nil,
+ resources: [Resource]? = nil,
+ publicHeadersPath: String? = nil,
+ cSettings: [CSetting]? = nil,
+ cxxSettings: [CXXSetting]? = nil,
+ swiftSettings: [SwiftSetting]? = nil,
+ linkerSettings: [LinkerSetting]? = nil
+) -> Target {
+ return Target(
+ name: name,
+ dependencies: dependencies,
+ path: path,
+ exclude: exclude,
+ sources: sources,
+ resources: resources,
+ publicHeadersPath: publicHeadersPath,
+ type: .executable,
+ cSettings: cSettings,
+ cxxSettings: cxxSettings,
+ swiftSettings: swiftSettings,
+ linkerSettings: linkerSettings
+ )
+}
+```
+
+A new `.executable` case is also added to the `TargetType` enum in the
+`PackageDescription` API.
+
+These are the only API changes that are visible to package manifest authors.
+
+On the implementation side, this proposal also updates the logic in SwiftPM
+so that:
+
+- if the package tools-version is less than 5.4, a target is considered to be
+ executable in exactly the same way as in versions of SwiftPM prior to 5.4
+- if the package tools-version is greater than or equal to 5.4, then:
+ - if the target is declared using `.executableTarget`, then it is considered
+ to be an executable target
+ - if the target is declared using `.target`, then source files are examined
+ using the same rules as prior to 5.4, and a warning suggesting that the
+ target be declared using `.executableTarget` is emitted if the target is
+ considered executable under those rules
+
+The effect of this logic is that, starting with SwiftPM tools-version 5.4,
+declaring an executable target by using `.target` and having it inferred to be
+an executable by the presence of a source file with a base name of `main` is
+considered deprecated but still works.
+
+This approach eases the transition for any package that adopts tools-version
+5.4, and provides better diagnostics to change the declarations of executable
+targets to use `.executableTarget`. If technically feasible, the warning
+should have a fix-it to change the associated `.target` declaration to
+`.executableTarget`.
+
+A future tools-version will remove the warning and treat any target that is
+declared using `.target` as a library target.
+
+SwiftPM already passes different flags when compiling executable targets and
+library targets, and that remains unchanged. In particular, SwiftPM passes
+`-parse-as-library` when compiling a non-executable target, and will continue
+to do so with these changes. It will continue to not pass this flag when
+compiling executable targets, so that the compiler will continue to interpret
+`main.swift` as the main source file of an executable.
+
+## Impact on existing packages
+
+There is no impact on existing packages. Packages that specify a tools-version
+of 5.4 or greater will get the new behavior. Any package graph can contain a
+mixture of old and new packages, and each target's executability will be
+determined according to the tools-version of the package that declares it.
+
+As with any Swift module, the Swift compiler will not let an executable have
+multiple `@main` entry points, including one that is specified by having a
+`main.swift` source file in the target.
+
+## Alternatives considered
+
+There are various other ways that could have been considered for designating
+a target as executable:
+
+#### As a new parameter on `target`
+
+Target declaration functions already have many parameters, and this would
+exacerbate that problem. It would also make it difficult to syntactically
+distinguish between executable targets and library targets in the package
+manifest. It would also make it difficult to add future parameters that
+applied to only library targets or executable targets.
+
+#### Through some other designation outside the manifest
+
+Since the intended executability of a target is a fundamental statement of
+purpose, it seems logical that this should be denoted in the package manifest.
+The Swift package manifest provides all the information other than what can be
+inferred from the file system.
+
+## Future directions
+
+It is somewhat redundant that a package having only a single executable target
+that builds a single executable product will now have both a product and target
+with the word "executable" in its type. This is mitigated by the existing Swift
+Package Manager behavior of implicitly creating an executable product for any
+executable target if there isn't already a product with the same name (this
+behavior remains unchanged by this proposal).
+
+Since a future goal is to find a way to unify product and target declarations
+in the package manifest, the redundant appearance of the word "executable" in
+both product and target type names is expected to be only a short-term issue.
diff --git a/proposals/0295-codable-synthesis-for-enums-with-associated-values.md b/proposals/0295-codable-synthesis-for-enums-with-associated-values.md
new file mode 100644
index 0000000000..599e2db532
--- /dev/null
+++ b/proposals/0295-codable-synthesis-for-enums-with-associated-values.md
@@ -0,0 +1,412 @@
+# Codable synthesis for enums with associated values
+
+* Proposal: [SE-0295](0295-codable-synthesis-for-enums-with-associated-values.md)
+* Authors: [Dario Rexin](https://github.com/drexin)
+* Review Manager: [Saleem Abdulrasool](https://github.com/compnerd)
+* Status: **Implemented (Swift 5.5)**
+* Implementation: [apple/swift#34855](https://github.com/apple/swift/pull/34855)
+* Pitch: [Forum Discussion](https://forums.swift.org/t/codable-synthesis-for-enums-with-associated-values/41493)
+* Previous Review: [Forum Discussion](https://forums.swift.org/t/se-0295-codable-synthesis-for-enums-with-associated-values/42408)
+* Previous Review 2: [Forum Discussion](https://forums.swift.org/t/se-0295-codable-synthesis-for-enums-with-associated-values-second-review/44036)
+
+## Introduction
+
+Codable was introduced in [SE-0166](https://github.com/swiftlang/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md)
+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 will extend the support for auto-synthesis of these conformances
+to enums with associated values.
+
+## Motivation
+
+Currently auto-synthesis only works for enums conforming to `RawRepresentable`.
+There have been discussions about adding general support for enums in the past,
+but the concrete structure of the encoded values was never agreed upon.
+We believe that having a solution for this is an important quality of life
+improvement.
+
+## Proposed solution
+
+There are two models of evolution, the one designated by the language and one that is useful in the regular use of enumerations. This proposal subsets the supported cases of automatic synthesis of Codable where the two models align. We believe this to be important to retain flexibility for the user to change the shape of the enumeration.
+
+### Structure of encoded enums
+
+The following enum with associated values
+
+```swift
+enum Command: Codable {
+ case load(key: String)
+ case store(key: String, value: Int)
+}
+```
+
+would be encoded to
+
+```json
+{
+ "load": {
+ "key": "MyKey"
+ }
+}
+```
+
+and
+
+```json
+{
+ "store": {
+ "key": "MyKey",
+ "value": 42
+ }
+}
+```
+
+The top-level container contains a single key that matches the name of the enum case,
+which points to another container that contains the values as they would be encoded
+for structs and classes.
+
+Associated values can also be unlabeled, in which case an identifier will be generated in the form of `_$N`, where `$N` is the 0-based position of the parameter. Using generated identifiers allows more flexibility in evolution of models than using an `UnkeyedContainer` would. If a user defined parameter has an identifier that conflicts with a generated identifier, the compiler will produce a diagnostic message.
+
+```swift
+enum Command: Codable {
+ case load(String)
+ case store(key: String, Int)
+}
+```
+
+would encoded to
+
+```json
+{
+ "load": {
+ "_0": "MyKey"
+ }
+}
+```
+
+and
+
+```json
+{
+ "store": {
+ "key": "MyKey",
+ "_1": 42
+ }
+}
+```
+
+An enum case without associated values would be encoded as an empty `KeyedContainer`,
+i.e.
+
+```swift
+enum Command: Codable {
+ case dumpToDisk
+}
+```
+
+would encode to:
+
+```json
+{
+ "dumpToDisk": {}
+}
+```
+
+This allows these cases to evolve in the same manner as cases with associated values, without breaking compatibility.
+
+### Synthesized code
+
+Given that enums are encoded into a nested structure, there are multiple `CodingKeys` declarations. One
+that contains the keys for each of the enum cases, which as before is called `CodingKeys`, and one for each case that contain the keys for the
+associated values, that are prefixed with the capilized case name, e.g. `LoadCodingKeys` for `case load`.
+
+```swift
+enum Command: Codable {
+ case load(key: String)
+ case store(key: String, value: Int)
+}
+```
+
+Would have the compiler generate the following `CodingKeys` declarations:
+
+```swift
+
+// contains keys for all cases of the enum
+enum CodingKeys: CodingKey {
+ case load
+ case store
+}
+
+// contains keys for all associated values of `case load`
+enum LoadCodingKeys: CodingKey {
+ case key
+}
+
+// contains keys for all associated values of `case store`
+enum StoreCodingKeys: CodingKey {
+ case key
+ case value
+}
+```
+
+The `encode(to:)` implementation would look as follows:
+
+```swift
+public func encode(to encoder: Encoder) throws {
+ var container = encoder.container(keyedBy: CodingKeys.self)
+ switch self {
+ case let .load(key):
+ var nestedContainer = container.nestedContainer(keyedBy: LoadCodingKeys.self, forKey: .load)
+ try nestedContainer.encode(key, forKey: .key)
+ case let .store(key, value):
+ var nestedContainer = container.nestedContainer(keyedBy: StoreCodingKeys.self, forKey: .store)
+ try nestedContainer.encode(key, forKey: .key)
+ try nestedContainer.encode(value, forKey: .value)
+ }
+}
+```
+
+and the `init(from:)` implementation would look as follows:
+
+```swift
+public init(from decoder: Decoder) throws {
+ let container = try decoder.container(keyedBy: CodingKeys.self)
+ if container.allKeys.count != 1 {
+ let context = DecodingError.Context(
+ codingPath: container.codingPath,
+ debugDescription: "Invalid number of keys found, expected one.")
+ throw DecodingError.typeMismatch(Command.self, context)
+ }
+
+ switch container.allKeys.first.unsafelyUnwrapped {
+ case .load:
+ let nestedContainer = try container.nestedContainer(keyedBy: LoadCodingKeys.self, forKey: .load)
+ self = .load(
+ key: try nestedContainer.decode(String.self, forKey: .key))
+ case .store:
+ let nestedContainer = try container.nestedContainer(keyedBy: StoreCodingKeys.self, forKey: .store)
+ self = .store(
+ key: try nestedContainer.decode(String.self, forKey: .key),
+ value: try nestedContainer.decode(Int.self, forKey: .value))
+ }
+}
+```
+
+### User customization
+
+For the existing cases, users can customize which properties are included in the encoded representation
+and map the property name to a custom name for the encoded representation by providing a custom `CodingKeys`
+declaration, instead of having the compiler generate one. The same should apply to the enum case.
+
+Users can define custom `CodingKeys` declarations for all, or a subset
+of the cases. If some of the cases in an enum should not be codable,
+they can be excluded from the `CodingKeys` declaration.
+
+**Example**
+
+```swift
+enum Command: Codable {
+ case load(key: String)
+ case store(key: String, value: Int)
+ case dumpToDisk
+
+ enum CodingKeys: CodingKey {
+ case load
+ case store
+ // don't include `dumpToDisk`
+ }
+}
+```
+
+The compiler will now only synthesize the code for the `load` and `store`
+cases. An attempt to en- or decode a `dumpToDisk` value will cause an error
+to be thrown.
+
+Customizing which values will be included follows the same rules as the
+existing functionality. Values that are excluded must have a default value
+defined, if a `Decodable` conformance should be synthesized. If only `Encodable`
+is synthesized, this restriction does not apply.
+
+**Example**
+
+```swift
+enum Command: Codable {
+ case load(key: String, someLocalInfo: Int)
+
+ // invalid, because `someLocalInfo` has no default value
+ enum LoadCodingKeys: CodingKey {
+ case key
+ }
+}
+```
+
+```swift
+enum Command: Codable {
+ case load(key: String, someLocalInfo: Int = 0)
+
+ // valid, because `someLocalInfo` has a default value
+ enum LoadCodingKeys: CodingKey {
+ case key
+ }
+}
+```
+
+```swift
+enum Command: Codable {
+ case load(key: String)
+
+ // invalid, because `someUnknownKey` does not map to a parameter in `load`
+ enum LoadCodingKeys: CodingKey {
+ case key
+ case someUnknownKey
+ }
+}
+```
+
+Keys can be mapped to other names by conforming to `RawRepresentable`:
+
+**Example**
+
+```swift
+enum Command: Codable {
+ case load(key: String)
+ case store(key: String, Int)
+
+ enum CodingKeys: String, CodingKey {
+ case load = "lade"
+ }
+
+ enum LoadCodingKeys: String, CodingKey {
+ case key = "schluessel"
+ }
+}
+```
+
+would encode to:
+
+```json
+{
+ "lade": {
+ "schluessel": "MyKey"
+ }
+}
+```
+
+### Evolution and compatibility
+
+Enum cases can evolve in the same way as structs and classes. Adding new fields, or removing existing ones is compatible, as long as the values are optional and the identifiers for the other cases don't change. This is in opposition to the evolution model of the language, where adding or removing associated values is a source and binary breaking change. We believe that a lot of use cases benefit from the ability to evolve the model, where source and binary compatibility are not an issue, e.g. in applications, services, or for internal types. If binary compatibility is important, evolution can be supported by having a single struct or class with all the parameters as the associated value.
+
+### Unsupported cases
+
+This proposal specifically does not support auto-synthesis for enums with overloaded case identifiers. This decision has been made because there is no clear way to support the feature, while also allowing the model to evolve, without severe restrictions. The separate cases in an enum typically have different semantics associated with them, so it is crucial to be able to properly identify the different cases and reject unknown cases.
+
+#### Evolution with overloaded case identifiers
+
+In this proposal, we are using keys as descriminators. For overloaded case names that would not be sufficient to identify the different overloads. An alternative would be to use the full name, including labels, e.g. `"store(key:,value:)"` for `case store(key: String, value: Int)`. This leads to several problems.
+
+1. Not a valid enum case identifier, so no user customization possible
+2. Not forward/backward compatible because it changes when parameters are added
+
+An alternative solution would be to match the keys against the parameter names when decoding an object. This approach also has issues. Overloads can share parameter names, so a message that contains additional keys, that the current code version does not know about, would cause ambiguity.
+
+**Example**
+
+```swift
+enum Test: Codable {
+ case x(y: Int)
+}
+```
+
+```json
+{
+ "x": {
+ "y": 42,
+ "z": "test"
+ }
+}
+```
+
+This could either mean that a parameter has been added to the existing case in a new code version, which should be ok under backwards compatibility rules, but could also mean that an overload has been added that partially matches the original case. If it is a different case, we should reject the message, but there is no way for the old code to decide this.
+
+#### Ambiguities without evolution
+
+Even when ignoring evolution, ambiguities exist with overloaded case identifiers. If two overloads share the same parameter names and one of them has additional optional parameters, the encoder can decide to drop `nil` values. This would cause ambiguities when only the shared keys are present.
+
+**Example**
+
+```swift
+enum Test: Codable {
+ case x(y: Int)
+ case x(y: Int, z: String?)
+}
+```
+
+Both cases would match the following input:
+
+```json
+{
+ "x": {
+ "y": 42
+ }
+}
+```
+
+Another ambiguity can be created by using the same parameter names for two overloads, only in a different order. Some formats do not guarantee the ordering of the keys, so the following definition leads to ambiguity when decoding:
+
+```swift
+enum Test: Codable {
+ case x(y: Int, z: String)
+ case x(z: String, y: Int)
+}
+```
+
+Both cases would match the following input:
+
+```json
+{
+ "x" : {
+ "y": 42,
+ "z": "test"
+ }
+}
+```
+
+## Source compatibility
+
+Existing source is not affected by these changes.
+
+## Effect on ABI stability
+
+None
+
+## Effect on API resilience
+
+None
+
+## Alternatives considered
+
+Previous discussions in the forums have been considered, specifically separating
+the discriminator and value into individual key/value pairs discussed in [this forum thread](https://forums.swift.org/t/automatic-codable-conformance-for-enums-with-associated-values-that-themselves-conform-to-codable/11499).
+While we do believe that there is value in doing this, we think that the default
+behavior should more closely follow the structure of the types that are encoded.
+A future proposal could add customization options to change the structure to meet
+individual requirements.
+
+### Parameterless cases
+
+Alternative ways to encode these cases have been discussed and the following problems have been found:
+
+1. Encode as plain values, as we do today with `RawRepresentable`
+
+The problem with this is that `Decoder` does not have APIs to check which type of container is present and adding such APIs would be a breaking change. The existing APIs to read containers are `throws`, but it is not specified in which cases an error should occur.
+
+2. Encode as `nil`
+
+This representation is problematic, because `Encoder` implementations can decide to drop `nil` values, which would also mean losing the key and with it the ability to identify the case.
+
+
+## Acknowledgements
+
+While iterating on this proposal, a lot of inspiration was drawn from the Rust library [serde](https://serde.rs/container-attrs.html).
diff --git a/proposals/0296-async-await.md b/proposals/0296-async-await.md
new file mode 100644
index 0000000000..6c32790ac6
--- /dev/null
+++ b/proposals/0296-async-await.md
@@ -0,0 +1,770 @@
+# Async/await
+
+* Proposal: [SE-0296](0296-async-await.md)
+* Authors: [John McCall](https://github.com/rjmccall), [Doug Gregor](https://github.com/DougGregor)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 5.5)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318), [Amendment to allow overloading on `async`](https://forums.swift.org/t/accepted-amendment-to-se-0296-allow-overloads-that-differ-only-in-async/50117)
+
+## Table of Contents
+
+ * [Async/await](#asyncawait)
+ * [Introduction](#introduction)
+ * [Motivation: Completion handlers are suboptimal](#motivation-completion-handlers-are-suboptimal)
+ * [Proposed solution: async/await](#proposed-solution-asyncawait)
+ * [Suspension points](#suspension-points)
+ * [Detailed design](#detailed-design)
+ * [Asynchronous functions](#asynchronous-functions)
+ * [Asynchronous function types](#asynchronous-function-types)
+ * [Await expressions](#await-expressions)
+ * [Closures](#closures)
+ * [Overloading and overload resolution](#overloading-and-overload-resolution)
+ * [Autoclosures](#autoclosures)
+ * [Protocol conformance](#protocol-conformance)
+ * [Source compatibility](#source-compatibility)
+ * [Effect on ABI stability](#effect-on-abi-stability)
+ * [Effect on API resilience](#effect-on-api-resilience)
+ * [Future Directions](#future-directions)
+ * [reasync](#reasync)
+ * [Alternatives Considered](#alternatives-considered)
+ * [Make await imply try](#make-await-imply-try)
+ * [Launching async tasks](#launching-async-tasks)
+ * [Await as syntactic sugar](#await-as-syntactic-sugar)
+ * [Revision history](#revision-history)
+ * [Related proposals](#related-proposals)
+ * [Acknowledgments](#acknowledgments)
+
+## Introduction
+
+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.
+
+This design introduces a [coroutine model](https://en.wikipedia.org/wiki/Coroutine) to Swift. Functions can opt into being `async`, allowing the programmer to compose complex logic involving asynchronous operations using the normal control-flow mechanisms. The compiler is responsible for translating an asynchronous function into an appropriate set of closures and state machines.
+
+This proposal defines the semantics of asynchronous functions. However, it does not provide concurrency: that is covered by a separate proposal to introduce structured concurrency, which associates asynchronous functions with concurrently-executing tasks and provides APIs for creating, querying, and cancelling tasks.
+
+Swift-evolution thread: [Pitch #1](https://forums.swift.org/t/concurrency-asynchronous-functions/41619), [Pitch #2](https://forums.swift.org/t/pitch-2-async-await/42420)
+
+## Motivation: Completion handlers are suboptimal
+
+Async programming with explicit callbacks (also called completion handlers) has many problems, which we’ll explore below. We propose to address these problems by introducing async functions into the language. Async functions allow asynchronous code to be written as straight-line code. They also allow the implementation to directly reason about the execution pattern of the code, allowing callbacks to run far more efficiently.
+
+#### Problem 1: Pyramid of doom
+
+A sequence of simple asynchronous operations often requires deeply-nested closures. Here is a made-up example showing this:
+
+```swift
+func processImageData1(completionBlock: (_ result: Image) -> Void) {
+ loadWebResource("dataprofile.txt") { dataResource in
+ loadWebResource("imagedata.dat") { imageResource in
+ decodeImage(dataResource, imageResource) { imageTmp in
+ dewarpAndCleanupImage(imageTmp) { imageResult in
+ completionBlock(imageResult)
+ }
+ }
+ }
+ }
+}
+
+processImageData1 { image in
+ display(image)
+}
+```
+
+This "pyramid of doom" makes it difficult to read and keep track of where the code is running. In addition, having to use a stack of closures leads to many second order effects that we will discuss next.
+
+#### Problem 2: Error handling
+
+Callbacks make error handling difficult and very verbose. Swift 2 introduced an error handling model for synchronous code, but callback-based interfaces do not derive any benefit from it:
+
+```swift
+// (2a) Using a `guard` statement for each callback:
+func processImageData2a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
+ loadWebResource("dataprofile.txt") { dataResource, error in
+ guard let dataResource = dataResource else {
+ completionBlock(nil, error)
+ return
+ }
+ loadWebResource("imagedata.dat") { imageResource, error in
+ guard let imageResource = imageResource else {
+ completionBlock(nil, error)
+ return
+ }
+ decodeImage(dataResource, imageResource) { imageTmp, error in
+ guard let imageTmp = imageTmp else {
+ completionBlock(nil, error)
+ return
+ }
+ dewarpAndCleanupImage(imageTmp) { imageResult, error in
+ guard let imageResult = imageResult else {
+ completionBlock(nil, error)
+ return
+ }
+ completionBlock(imageResult)
+ }
+ }
+ }
+ }
+}
+
+processImageData2a { image, error in
+ guard let image = image else {
+ display("No image today", error)
+ return
+ }
+ display(image)
+}
+```
+
+The addition of [`Result`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0235-add-result.md) to the standard library improved on error handling for Swift APIs. Asynchronous APIs were one of the [main motivators](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0235-add-result.md#asynchronous-apis) for `Result`:
+
+```swift
+// (2b) Using a `do-catch` statement for each callback:
+func processImageData2b(completionBlock: (Result) -> Void) {
+ loadWebResource("dataprofile.txt") { dataResourceResult in
+ do {
+ let dataResource = try dataResourceResult.get()
+ loadWebResource("imagedata.dat") { imageResourceResult in
+ do {
+ let imageResource = try imageResourceResult.get()
+ decodeImage(dataResource, imageResource) { imageTmpResult in
+ do {
+ let imageTmp = try imageTmpResult.get()
+ dewarpAndCleanupImage(imageTmp) { imageResult in
+ completionBlock(imageResult)
+ }
+ } catch {
+ completionBlock(.failure(error))
+ }
+ }
+ } catch {
+ completionBlock(.failure(error))
+ }
+ }
+ } catch {
+ completionBlock(.failure(error))
+ }
+ }
+}
+
+processImageData2b { result in
+ do {
+ let image = try result.get()
+ display(image)
+ } catch {
+ display("No image today", error)
+ }
+}
+```
+
+```swift
+// (2c) Using a `switch` statement for each callback:
+func processImageData2c(completionBlock: (Result) -> Void) {
+ loadWebResource("dataprofile.txt") { dataResourceResult in
+ switch dataResourceResult {
+ case .success(let dataResource):
+ loadWebResource("imagedata.dat") { imageResourceResult in
+ switch imageResourceResult {
+ case .success(let imageResource):
+ decodeImage(dataResource, imageResource) { imageTmpResult in
+ switch imageTmpResult {
+ case .success(let imageTmp):
+ dewarpAndCleanupImage(imageTmp) { imageResult in
+ completionBlock(imageResult)
+ }
+ case .failure(let error):
+ completionBlock(.failure(error))
+ }
+ }
+ case .failure(let error):
+ completionBlock(.failure(error))
+ }
+ }
+ case .failure(let error):
+ completionBlock(.failure(error))
+ }
+ }
+}
+
+processImageData2c { result in
+ switch result {
+ case .success(let image):
+ display(image)
+ case .failure(let error):
+ display("No image today", error)
+ }
+}
+```
+
+It's easier to handle errors when using `Result`, but the closure-nesting problem remains.
+
+#### Problem 3: Conditional execution is hard and error-prone
+
+Conditionally executing an asynchronous function is a huge pain. For example, suppose we need to "swizzle" an image after obtaining it. But, we sometimes have to make an asynchronous call to decode the image before we can swizzle. Perhaps the best approach to structuring this function is to write the swizzling code in a helper "continuation" closure that is conditionally captured in a completion handler, like this:
+
+```swift
+func processImageData3(recipient: Person, completionBlock: (_ result: Image) -> Void) {
+ let swizzle: (_ contents: Image) -> Void = {
+ // ... continuation closure that calls completionBlock eventually
+ }
+ if recipient.hasProfilePicture {
+ swizzle(recipient.profilePicture)
+ } else {
+ decodeImage { image in
+ swizzle(image)
+ }
+ }
+}
+```
+
+This pattern inverts the natural top-down organization of the function: the code that will execute in the second half of the function must appear *before* the part that executes in the first half. In addition to restructuring the entire function, we must now think carefully about captures in the continuation closure, because the closure is used in a completion handler. The problem worsens as the number of conditionally-executed async functions grows, yielding what is essentially an inverted "pyramid of doom."
+
+#### Problem 4: Many mistakes are easy to make
+
+It's quite easy to bail-out of the asynchronous operation early by simply returning without calling the correct completion-handler block. When forgotten, the issue is very hard to debug:
+
+```swift
+func processImageData4a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
+ loadWebResource("dataprofile.txt") { dataResource, error in
+ guard let dataResource = dataResource else {
+ return // <- forgot to call the block
+ }
+ loadWebResource("imagedata.dat") { imageResource, error in
+ guard let imageResource = imageResource else {
+ return // <- forgot to call the block
+ }
+ ...
+ }
+ }
+}
+```
+
+When you do remember to call the block, you can still forget to return after that:
+
+```swift
+func processImageData4b(recipient:Person, completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
+ if recipient.hasProfilePicture {
+ if let image = recipient.profilePicture {
+ completionBlock(image) // <- forgot to return after calling the block
+ }
+ }
+ ...
+}
+```
+
+Thankfully the `guard` syntax protects against forgetting to return to some degree, but it's not always relevant.
+
+#### Problem 5: Because completion handlers are awkward, too many APIs are defined synchronously
+
+This is hard to quantify, but the authors believe that the awkwardness of defining and using asynchronous APIs (using completion handlers) has led to many APIs being defined with apparently synchronous behavior, even when they can block. This can lead to problematic performance and responsiveness problems in UI applications, e.g. a spinning cursor. It can also lead to the definition of APIs that cannot be used when asynchrony is critical to achieve scale, e.g. on the server.
+
+## Proposed solution: async/await
+
+Asynchronous functions—often known as async/await—allow asynchronous code to be written as if it were straight-line, synchronous code. This immediately addresses many of the problems described above by allowing programmers to make full use of the same language constructs that are available to synchronous code. The use of async/await also naturally preserves the semantic structure of the code, providing information necessary for at least three cross-cutting improvements to the language: (1) better performance for asynchronous code; (2) better tooling to provide a more consistent experience while debugging, profiling, and exploring code; and (3) a foundation for future concurrency features like task priority and cancellation. The example from the prior section demonstrates how async/await drastically simplifies asynchronous code:
+
+```swift
+func loadWebResource(_ path: String) async throws -> Resource
+func decodeImage(_ r1: Resource, _ r2: Resource) async throws -> Image
+func dewarpAndCleanupImage(_ i : Image) async throws -> Image
+
+func processImageData() async throws -> Image {
+ let dataResource = try await loadWebResource("dataprofile.txt")
+ let imageResource = try await loadWebResource("imagedata.dat")
+ let imageTmp = try await decodeImage(dataResource, imageResource)
+ let imageResult = try await dewarpAndCleanupImage(imageTmp)
+ return imageResult
+}
+```
+
+Many descriptions of async/await discuss it through a common implementation mechanism: a compiler pass which divides a function into multiple components. This is important at a low level of abstraction in order to understand how the machine is operating, but at a high level we’d like to encourage you to ignore it. Instead, think of an asynchronous function as an ordinary function that has the special power to give up its thread. Asynchronous functions don’t typically use this power directly; instead, they make calls, and sometimes these calls will require them to give up their thread and wait for something to happen. When that thing is complete, the function will resume executing again.
+
+The analogy with synchronous functions is very strong. A synchronous function can make a call; when it does, the function immediately waits for the call to complete. Once the call completes, control returns to the function and picks up where it left off. The same thing is true with an asynchronous function: it can make calls as usual; when it does, it (normally) immediately waits for the call to complete. Once the call completes, control returns to the function and it picks up where it was. The only difference is that synchronous functions get to take full advantage of (part of) their thread and its stack, whereas *asynchronous functions are able to completely give up that stack and use their own, separate storage*. This additional power given to asynchronous functions has some implementation cost, but we can reduce that quite a bit by designing holistically around it.
+
+Because asynchronous functions must be able to abandon their thread, and synchronous functions don’t know how to abandon a thread, a synchronous function can’t ordinarily call an asynchronous function: the asynchronous function would only be able to give up the part of the thread it occupied, and if it tried, its synchronous caller would treat it like a return and try to pick up where it was, only without a return value. The only way to make this work in general would be to block the entire thread until the asynchronous function was resumed and completed, and that would completely defeat the purpose of asynchronous functions, as well as having nasty systemic effects.
+
+In contrast, an asynchronous function can call either synchronous or asynchronous functions. While it’s calling a synchronous function, of course, it can’t give up its thread. In fact, asynchronous functions never just spontaneously give up their thread; they only give up their thread when they reach what’s called a suspension point. A suspension point can occur directly within a function, or it can occur within another asynchronous function that the function calls, but in either case the function and all of its asynchronous callers simultaneously abandon the thread. (In practice, asynchronous functions are compiled to not depend on the thread during an asynchronous call, so that only the innermost function needs to do any extra work.)
+
+When control returns to an asynchronous function, it picks up exactly where it was. That doesn’t necessarily mean that it’ll be running on the exact same thread it was before, because the language doesn’t guarantee that after a suspension. In this design, threads are mostly an implementation mechanism, not a part of the intended interface to concurrency. However, many asynchronous functions are not just asynchronous: they’re also associated with specific actors (which are the subject of a separate proposal), and they’re always supposed to run as part of that actor. Swift does guarantee that such functions will in fact return to their actor to finish executing. Accordingly, libraries that use threads directly for state isolation—for example, by creating their own threads and scheduling tasks sequentially onto them—should generally model those threads as actors in Swift in order to allow these basic language guarantees to function properly.
+
+### Suspension points
+
+A suspension point is a point in the execution of an asynchronous function where it has to give up its thread. Suspension points are always associated with some deterministic, syntactically explicit event in the function; they’re never hidden or asynchronous from the function’s perspective. The primary form of suspension point is a call to an asynchronous function associated with a different execution context.
+
+It is important that suspension points are only associated with explicit operations. In fact, it’s so important that this proposal requires that calls that *might* suspend be enclosed in an `await` expression. These calls are referred to as *potential suspension points*, because it is not known statically whether they will actually suspend: that depends both on code not visible at the call site (e.g., the callee might depend on asynchronous I/O) as well as dynamic conditions (e.g., whether that asynchronous I/O will have to wait to complete).
+
+The requirement for `await` on potential suspension points follows Swift's precedent of requiring `try` expressions to cover calls to functions that can throw errors. Marking potential suspension points is particularly important because *suspensions interrupt atomicity*. For example, if an asynchronous function is running within a given context that is protected by a serial queue, reaching a suspension point means that other code can be interleaved on that same serial queue. A classic but somewhat hackneyed example where this atomicity matters is modeling a bank: if a deposit is credited to one account, but the operation suspends before processing a matched withdrawal, it creates a window where those funds can be double-spent. A more germane example for many Swift programmers is a UI thread: the suspension points are the points where the UI can be shown to the user, so programs that build part of their UI and then suspend risk presenting a flickering, partially-constructed UI. (Note that suspension points are also called out explicitly in code using explicit callbacks: the suspension happens between the point where the outer function returns and the callback starts running.) Requiring that all potential suspension points are marked allows programmers to safely assume that places without potential suspension points will behave atomically, as well as to more easily recognize problematic non-atomic patterns.
+
+Because potential suspension points can only appear at points explicitly marked within an asynchronous function, long computations can still block threads. This might happen when calling a synchronous function that just does a lot of work, or when encountering a particularly intense computational loop written directly in an asynchronous function. In either case, the thread cannot interleave code while these computations are running, which is usually the right choice for correctness, but can also become a scalability problem. Asynchronous programs that need to do intense computation should generally run it in a separate context. When that’s not feasible, there will be library facilities to artificially suspend and allow other operations to be interleaved.
+
+Asynchronous functions should avoid calling functions that can actually block the thread, especially if they can block it waiting for work that’s not guaranteed to be currently running. For example, acquiring a mutex can only block until some currently-running thread gives up the mutex; this is sometimes acceptable but must be used carefully to avoid introducing deadlocks or artificial scalability problems. In contrast, waiting on a condition variable can block until some arbitrary other work gets scheduled that signals the variable; this pattern goes strongly against recommendation.
+
+## Detailed design
+
+### Asynchronous functions
+
+Function types can be marked explicitly as `async`, indicating that the function is asynchronous:
+
+```swift
+func collect(function: () async -> Int) { ... }
+```
+
+A function or initializer declaration can also be declared explicitly as `async`:
+
+```swift
+class Teacher {
+ init(hiringFrom: College) async throws {
+ ...
+ }
+
+ private func raiseHand() async -> Bool {
+ ...
+ }
+}
+```
+
+> **Rationale**: The `async` follows the parameter list because it is part of the function's type as well as its declaration. This follows the precedent of `throws`.
+
+The type of a reference to a function or initializer declared `async` is an `async` function type. If the reference is a “curried” static reference to an instance method, it is the "inner" function type that is `async`, consistent with the usual rules for such references.
+
+Special functions like `deinit` and storage accessors (i.e., the getters and setters for properties and subscripts) cannot be `async`.
+
+> **Rationale**: Properties and subscripts that only have a getter could potentially be `async`. However, properties and subscripts that also have an `async` setter imply the ability to pass the reference as `inout` and drill down into the properties of that property itself, which depends on the setter effectively being an "instantaneous" (synchronous, non-throwing) operation. Prohibiting `async` properties is a simpler rule than only allowing get-only `async` properties and subscripts.
+
+If a function is both `async` and `throws`, then the `async` keyword must precede `throws` in the type declaration. This same rule applies if `async` and `rethrows`.
+
+> **Rationale** : This order restriction is arbitrary, but it's not harmful, and it eliminates the potential for stylistic debates.
+
+An `async` initializer of a class that has a superclass but lacks a call to a superclass initializer will get an implicit call to `super.init()` only if the superclass has a zero-argument, synchronous, designated initializer.
+
+> **Rationale**: If the superclass initializer is `async`, the call to the asynchronous initializer is a potential suspension point and therefore the call (and required `await`) must be visible in the source.
+
+### Asynchronous function types
+
+Asynchronous function types are distinct from their synchronous counterparts. However, there is an implicit conversion from a synchronous function type to its corresponding asynchronous function type. This is similar to the implicit conversion from a non-throwing function to its throwing counterpart, which can also compose with the asynchronous function conversion. For example:
+
+```swift
+struct FunctionTypes {
+ var syncNonThrowing: () -> Void
+ var syncThrowing: () throws -> Void
+ var asyncNonThrowing: () async -> Void
+ var asyncThrowing: () async throws -> Void
+
+ mutating func demonstrateConversions() {
+ // Okay to add 'async' and/or 'throws'
+ asyncNonThrowing = syncNonThrowing
+ asyncThrowing = syncThrowing
+ syncThrowing = syncNonThrowing
+ asyncThrowing = asyncNonThrowing
+
+ // Error to remove 'async' or 'throws'
+ syncNonThrowing = asyncNonThrowing // error
+ syncThrowing = asyncThrowing // error
+ syncNonThrowing = syncThrowing // error
+ asyncNonThrowing = syncThrowing // error
+ }
+}
+```
+
+### Await expressions
+
+A call to a value of `async` function type (including a direct call to an `async` function) introduces a potential suspension point.
+Any potential suspension point must occur within an asynchronous context (e.g., an `async` function). Furthermore, it must occur within the operand of an `await` expression.
+
+Consider the following example:
+
+```swift
+// func redirectURL(for url: URL) async -> URL { ... }
+// func dataTask(with: URL) async throws -> (Data, URLResponse) { ... }
+
+let newURL = await server.redirectURL(for: url)
+let (data, response) = try await session.dataTask(with: newURL)
+```
+
+In this code example, a task suspension may happen during the calls to `redirectURL(for:)` and `dataTask(with:)` because they are async functions. Thus, both call expressions must be contained within some `await` expression, because each call contains a potential suspension point. An `await` operand may contain more than one potential suspension point. For example, we can use one `await` to cover both potential suspension points from our example by rewriting it as:
+
+```swift
+let (data, response) = try await session.dataTask(with: server.redirectURL(for: url))
+```
+
+The `await` has no additional semantics; like `try`, it merely marks that an asynchronous call is being made. The type of the `await` expression is the type of its operand, and its result is the result of its operand.
+An `await` operand may also have no potential suspension points, which will result in a warning from the Swift compiler, following the precedent of `try` expressions:
+
+```swift
+let x = await synchronous() // warning: no calls to 'async' functions occur within 'await' expression
+```
+
+> **Rationale**: It is important that asynchronous calls are clearly identifiable within the function because they may introduce suspension points, which break the atomicity of the operation. The suspension points may be inherent to the call (because the asynchronous call must execute on a different executor) or simply be part of the implementation of the callee, but in either case it is semantically important and the programmer needs to acknowledge it. `await` expressions are also an indicator of asynchronous code, which interacts with inference in closures; see the section on [Closures](#closures) for more information.
+
+A potential suspension point must not occur within an autoclosure that is not of `async` function type.
+
+A potential suspension point must not occur within a `defer` block.
+
+If both `await` and a variant of `try` (including `try!` and `try?`) are applied to the same subexpression, `await` must follow the `try`/`try!`/`try?`:
+
+```swift
+let (data, response) = await try session.dataTask(with: server.redirectURL(for: url)) // error: must be `try await`
+let (data, response) = await (try session.dataTask(with: server.redirectURL(for: url))) // okay due to parentheses
+```
+
+> **Rationale**: this restriction is arbitrary, but follows the equally-arbitrary restriction on the ordering of `async throws` in preventing stylistic debates.
+
+### Closures
+
+A closure can have `async` function type. Such closures can be explicitly marked as `async` as follows:
+
+```swift
+{ () async -> Int in
+ print("here")
+ return await getInt()
+}
+```
+
+An anonymous closure is inferred to have `async` function type if it contains an `await` expression.
+
+```swift
+let closure = { await getInt() } // implicitly async
+
+let closure2 = { () -> Int in // implicitly async
+ print("here")
+ return await getInt()
+}
+```
+
+Note that inference of `async` on a closure does not propagate to its enclosing or nested functions or closures, because those contexts are separably asynchronous or synchronous. For example, only `closure6` is inferred to be `async` in this situation:
+
+```swift
+// func getInt() async -> Int { ... }
+
+let closure5 = { () -> Int in // not 'async'
+ let closure6 = { () -> Int in // implicitly async
+ if randomBool() {
+ print("there")
+ return await getInt()
+ } else {
+ let closure7 = { () -> Int in 7 } // not 'async'
+ return 0
+ }
+ }
+
+ print("here")
+ return 5
+}
+```
+
+### Overloading and overload resolution
+
+Existing Swift APIs generally support asynchronous functions via a callback interface, e.g.,
+
+```swift
+func doSomething(completionHandler: ((String) -> Void)? = nil) { ... }
+```
+
+Many such APIs are likely to be updated by adding an `async` form:
+
+```swift
+func doSomething() async -> String { ... }
+```
+
+These two functions have different names and signatures, even though they share the same base name. However, either of them can be called with no parameters (due to the defaulted completion handler), which would present a problem for existing code:
+
+```swift
+doSomething() // problem: can call either, unmodified Swift rules prefer the `async` version
+```
+
+A similar problem exists for APIs that evolve into providing both a synchronous and an asynchronous version of the same function, with the same signature. Such pairs allow APIs to provide a new asynchronous function which better fits in the Swift asynchronous landscape, without breaking backward compatibility. New asynchronous functions can support, for example, cancellation (covered in the [Structured Concurrency](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md) proposal).
+
+```swift
+// Existing synchronous API
+func doSomethingElse() { ... }
+
+// New and enhanced asynchronous API
+func doSomethingElse() async { ... }
+```
+
+In the first case, Swift's overloading rules prefer to call a function with fewer default arguments, so the addition of the `async` function would break existing code that called the original `doSomething(completionHandler:)` with no completion handler. This would get an error along the lines of:
+
+```
+error: `async` function cannot be called from non-asynchronous context
+```
+
+This presents problems for code evolution, because developers of existing asynchronous libraries would have to either have a hard compatibility break (e.g, to a new major version) or would need have different names for all of the new `async` versions. The latter would likely result in a scheme such as [C#'s pervasive `Async` suffix](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model).
+
+The second case, where both functions have the same signature and only differ in `async`, is normally rejected by existing Swift's overloading rules. Those do not allow two functions to differ only in their *effects*, and one can not define two functions that only differ in `throws`, for example.
+
+```
+// error: redeclaration of function `doSomethingElse()`.
+```
+
+This also presents a problem for code evolution, because developers of existing libraries just could not preserve their existing synchronous APIs, and support new asynchronous features.
+
+Instead, we propose an overload-resolution rule to select the appropriate function based on the context of the call. Given a call, overload resolution prefers non-`async` functions within a synchronous context (because such contexts cannot contain a call to an `async` function). Furthermore, overload resolution prefers `async` functions within an asynchronous context (because such contexts should avoid stepping out of the asynchronous model into blocking APIs). When overload resolution selects an `async` function, that call is still subject to the rule that it must occur within an `await` expression.
+
+The overload-resolution rule depends on the synchronous or asynchronous context, in which the compiler selects one and only one overload. The selection of the async overload requires an `await` expression, as all introductions of a potential suspension point:
+
+```swift
+func f() async {
+ // In an asynchronous context, the async overload is preferred:
+ await doSomething()
+ // Compiler error: Expression is 'async' but is not marked with 'await'
+ doSomething()
+}
+```
+
+In non-`async` functions, and closures without any `await` expression, the compiler selects the non-`async` overload:
+
+```swift
+func f() async {
+ let f2 = {
+ // In a synchronous context, the non-async overload is preferred:
+ doSomething()
+ }
+ f2()
+}
+```
+
+
+### Autoclosures
+
+A function may not take an autoclosure parameter of `async` function type unless the function itself is `async`. For example, the following declaration is ill-formed:
+
+```swift
+// error: async autoclosure in a function that is not itself 'async'
+func computeArgumentLater(_ fn: @escaping @autoclosure () async -> T) { }
+```
+
+This restriction exists for several reasons. Consider the following example:
+
+ ```swift
+ // func getIntSlowly() async -> Int { ... }
+
+ let closure = {
+ computeArgumentLater(await getIntSlowly())
+ print("hello")
+ }
+ ```
+
+At first glance, the `await` expression implies to the programmer that there is a potential suspension point *prior* to the call to `computeArgumentLater(_:)`, which is not actually the case: the potential suspension point is *within* the (auto)closure that is passed and used within the body of `computeArgumentLater(_:)`. This causes a few problems. First, the fact that `await` appears to be prior to the call means that `closure` would be inferred to have `async` function type, which is also incorrect: all of the code in `closure` is synchronous. Second, because an `await`'s operand only needs to contain a potential suspension point somewhere within it, an equivalent rewriting of the call should be:
+
+```swift
+await computeArgumentLater(getIntSlowly())
+```
+
+But, because the argument is an autoclosure, this rewriting is no longer semantics-preserving. Thus, the restriction on `async` autoclosure parameters avoids these problems by ensuring that `async` autoclosure parameters can only be used in asynchronous contexts.
+
+### Protocol conformance
+
+A protocol requirement can be declared as `async`. Such a requirement can be satisfied by an `async` or synchronous function. However, a synchronous function requirement cannot be satisfied by an `async` function. For example:
+
+```swift
+protocol Asynchronous {
+ func f() async
+}
+
+protocol Synchronous {
+ func g()
+}
+
+struct S1: Asynchronous {
+ func f() async { } // okay, exactly matches
+}
+
+struct S2: Asynchronous {
+ func f() { } // okay, synchronous function satisfying async requirement
+}
+
+struct S3: Synchronous {
+ func g() { } // okay, exactly matches
+}
+
+struct S4: Synchronous {
+ func g() async { } // error: cannot satisfy synchronous requirement with an async function
+}
+```
+
+This behavior follows the subtyping/implicit conversion rule for asynchronous functions, as is precedented by the behavior of `throws`.
+
+## Source compatibility
+
+This proposal is generally additive: existing code does not use any of the new features (e.g., does not create `async` functions or closures) and will not be impacted. However, it introduces two new contextual keywords, `async` and `await`.
+
+The positions of the new uses of `async` within the grammar (function declarations and function types) allows us to treat `async` as a contextual keyword without breaking source compatibility. A user-defined `async` cannot occur in those grammatical positions in well-formed code.
+
+The `await` contextual keyword is more problematic, because it occurs within an expression. For example, one could define a function `await` in Swift today:
+
+```swift
+func await(_ x: Int, _ y: Int) -> Int { x + y }
+
+let result = await(1, 2)
+```
+
+This is well-formed code today that is a call to the `await` function. With this proposal, this code becomes an `await` expression with the subexpression `(1, 2)`. This will manifest as a compile-time error for existing Swift programs, because `await` can only be used within an asynchronous context, and no existing Swift programs have such a context. Such functions do not appear to be common, so we believe this is an acceptable source break as part of the introduction of async/await.
+
+## Effect on ABI stability
+
+Asynchronous functions and function types are additive to the ABI, so there is no effect on ABI stability, because existing (synchronous) functions and function types are unchanged.
+
+## Effect on API resilience
+
+The ABI for an `async` function is completely different from the ABI for a synchronous function (e.g., they have incompatible calling conventions), so the addition or removal of `async` from a function or type is not a resilient change.
+
+## Future Directions
+
+### `reasync`
+
+Swift's `rethrows` is a mechanism for indicating that a particular function is throwing only when one of the arguments passed to it is a function that itself throws. For example, `Sequence.map` makes use of `rethrows` because the only way the operation can throw is if the transform itself throws:
+
+```swift
+extension Sequence {
+ func map(transform: (Element) throws -> Transformed) rethrows -> [Transformed] {
+ var result = [Transformed]()
+ var iterator = self.makeIterator()
+ while let element = iterator.next() {
+ result.append(try transform(element)) // note: this is the only `try`!
+ }
+ return result
+ }
+}
+```
+
+Here are uses of `map` in practice:
+
+```swift
+_ = [1, 2, 3].map { String($0) } // okay: map does not throw because the closure does not throw
+_ = try ["1", "2", "3"].map { (string: String) -> Int in
+ guard let result = Int(string) else { throw IntParseError(string) }
+ return result
+} // okay: map can throw because the closure can throw
+```
+
+The same notion could be applied to `async` functions. For example, we could imagine making `map` asynchronous when its argument is asynchronous with `reasync`:
+
+```swift
+extension Sequence {
+ func map(transform: (Element) async throws -> Transformed) reasync rethrows -> [Transformed] {
+ var result = [Transformed]()
+ var iterator = self.makeIterator()
+ while let element = iterator.next() {
+ result.append(try await transform(element)) // note: this is the only `try` and only `await`!
+ }
+ return result
+ }
+}
+```
+
+*Conceptually*, this is fine: when provided with an `async` function, `map` will be treated as `async` (and you'll need to `await` the result), whereas providing it with a non-`async` function, `map` will be treated as synchronous (and won't require `await`).
+
+*In practice*, there are a few problems here:
+
+* This is probably not a very good implementation of an asynchronous `map` on a sequence. More likely, we would want a concurrent implementation that (say) processes up to number-of-cores elements concurrently.
+* The ABI of throwing functions is intentionally designed to make it possible for a `rethrows` function to act as a non-throwing function, so a single ABI entry point suffices for both throwing and non-throwing calls. The same is not true of `async` functions, which have a radically different ABI that is necessarily less efficient than the ABI for synchronous functions.
+
+For something like `Sequence.map` that might become concurrent, `reasync` is likely the wrong tool: overloading for `async` closures to provide a separate (concurrent) implementation is likely the better answer. So, `reasync` is likely to be much less generally applicable than `rethrows`.
+
+There are undoubtedly some uses for `reasync`, such as the `??` operator for optionals, where the `async` implementation degrades nicely to a synchronous implementation:
+
+```swift
+func ??(
+ _ optValue: T?, _ defaultValue: @autoclosure () async throws -> T
+) reasync rethrows -> T {
+ if let value = optValue {
+ return value
+ }
+
+ return try await defaultValue()
+}
+```
+
+For such cases, the ABI concern described above can likely be addressed by emitting two entrypoints: one when the argument is `async` and one when it is not. However, the implementation is complex enough that the authors are not yet ready to commit to this design.
+
+## Alternatives Considered
+
+### Make `await` imply `try`
+
+Many asynchronous APIs involve file I/O, networking, or other failable operations, and therefore will be both `async` and `throws`. At the call site, this means `try await` will be repeated many times. To reduce the boilerplate, `await` could imply `try`, so the following two lines would be equivalent:
+
+```swift
+let dataResource = await loadWebResource("dataprofile.txt")
+let dataResource = try await loadWebResource("dataprofile.txt")
+```
+
+We chose not to make `await` imply `try` because they are expressing different kinds of concerns: `await` is about a potential suspension point, where other code might execute in between when you make the call and it when it returns, while `try` is about control flow out of the block.
+
+One other motivation that has come up for making `await` imply `try` is related to task cancellation. If task cancellation were modeled as a thrown error, and every potential suspension point implicitly checked whether the task was cancelled, then every potential suspension point could throw: in such cases `await` might as well imply `try` because every `await` can potentially exit with an error.
+Task cancellation is covered in the [Structured Concurrency](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md) proposal, and does *not* model cancellation solely as a thrown error nor does it introduce implicit cancellation checks at each potential suspension point.
+
+### Launching async tasks
+
+Because only `async` code can call other `async` code, this proposal provides no way to initiate asynchronous code. This is intentional: all asynchronous code runs within the context of a "task", a notion which is defined in the [Structured Concurrency](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md) proposal. That proposal provides the ability to define asynchronous entry points to the program via `@main`, e.g.,
+
+```swift
+@main
+struct MyProgram {
+ static func main() async { ... }
+}
+```
+
+Additionally, top-level code is not considered an asynchronous context in this proposal, so the following program is ill-formed:
+
+```swift
+func f() async -> String { "hello, asynchronously" }
+
+print(await f()) // error: cannot call asynchronous function in top-level code
+```
+
+This, too, will be addressed in a subsequent proposal that properly accounts for
+top-level variables.
+
+None of the concerns for top-level code affect the fundamental mechanisms of async/await as defined in this proposal.
+
+### Await as syntactic sugar
+
+This proposal makes `async` functions a core part of the Swift type system, distinct from synchronous functions. An alternative design would leave the type system unchanged, and instead make `async` and `await` syntactic sugar over some `Future` type, e.g.,
+
+```swift
+async func processImageData() throws -> Future {
+ let dataResource = try loadWebResource("dataprofile.txt").await()
+ let imageResource = try loadWebResource("imagedata.dat").await()
+ let imageTmp = try decodeImage(dataResource, imageResource).await()
+ let imageResult = try dewarpAndCleanupImage(imageTmp).await()
+ return imageResult
+}
+```
+
+This approach has a number of downsides vs. the proposed approach here:
+
+* There is no universal `Future` type on which to build it in the Swift ecosystem. If the Swift ecosystem had mostly settled on a single future type already (e.g., if there were already one in the standard library), a syntactic-sugar approach like the above would codify existing practice. Lacking such a type, one would have to try to abstract over all of the different kinds of future types with some kind of `Futurable` protocol. This may be possible for some set of future types, but would give up any guarantees about the behavior or performance of asynchronous code.
+* It is inconsistent with the design of `throws`. The result type of asynchronous functions in this model is the future type (or "any `Futurable` type"), rather than the actual returned value. They must always be `await`'ed immediately (hence the postfix syntax) or you'll end up working with futures when you actually care about the result of the asynchronous operation. This becomes a programming-with-futures model rather than an asynchronous-programming model, when many other aspects of the `async` design intentionally push away from thinking about the futures.
+* Taking `async` out of the type system would eliminate the ability to do overloading based on `async`. See the prior section on the reasons for overloading on `async`.
+* Futures are relatively heavyweight types, and forming one for every async operation has nontrivial costs in both code size and performance. In contrast, deep integration with the type system allows `async` functions to be purpose-built and optimized for efficient suspension. All levels of the Swift compiler and runtime can optimize `async` functions in a manner that would not be possible with future-returning functions.
+
+## Revision history
+
+* Post-review changes:
+ * Replaced `await try` with `try await`.
+ * Added syntactic-sugar alternative design.
+ * Amended the proposal to allow [overloading on `async`](https://github.com/swiftlang/swift-evolution/pull/1392).
+* Changes in the second pitch:
+ * One can no longer directly overload `async` and non-`async` functions. Overload resolution support remains, however, with additional justification.
+ * Added an implicit conversion from a synchronous function to an asynchronous function.
+ * Added `await try` ordering restriction to match the `async throws` restriction.
+ * Added support for `async` initializers.
+ * Added support for synchronous functions satisfying an `async` protocol requirement.
+ * Added discussion of `reasync`.
+ * Added justification for `await` not implying `try`.
+ * Added justification for `async` following the function parameter list.
+
+* Original pitch ([document](https://github.com/DougGregor/swift-evolution/blob/092c05eebb48f6c0603cd268b7eaf455865c64af/proposals/nnnn-async-await.md) and [forum thread](https://forums.swift.org/t/concurrency-asynchronous-functions/41619)).
+
+## Related proposals
+
+In addition to this proposal, there are a number of related proposals covering different aspects of the Swift Concurrency model:
+
+* [Concurrency Interoperability with Objective-C](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0297-concurrency-objc.md): Describes the interaction with Objective-C, especially the relationship between asynchronous Objective-C methods that accept completion handlers and `@objc async` Swift methods.
+* [Structured Concurrency](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md): Describes the task structure used by asynchronous calls, the creation of both child tasks and detached tasks, cancellation, prioritization, and other task-management APIs.
+* [Actors](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0306-actors.md): Describes the actor model, which provides state isolation for concurrent programs
+
+## Acknowledgments
+
+The desire for async/await in Swift has been around for a long time. This proposal draws some inspiration (and most of the Motivation section) from an earlier proposal written by
+[Chris Lattner](https://github.com/lattner) and [Joe Groff](https://github.com/jckarter), available [here](https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619). That proposal itself is derived from a proposal written by [Oleg Andreev](https://github.com/oleganza), available [here](https://gist.github.com/oleganza/7342ed829bddd86f740a). It has been significantly rewritten (again), and many details have changed, but the core ideas of asynchronous functions have remained the same.
+
+Efficient implementation is critical for the introduction of asynchronous functions, and Swift Concurrency as a whole. Nate Chandler, Erik Eckstein, Kavon Farvardin, Joe Groff, Chris Lattner, Slava Pestov, and Arnold Schwaighofer all made significant contributions to the implementation of this proposal.
diff --git a/proposals/0297-concurrency-objc.md b/proposals/0297-concurrency-objc.md
new file mode 100644
index 0000000000..a0caa5de14
--- /dev/null
+++ b/proposals/0297-concurrency-objc.md
@@ -0,0 +1,357 @@
+# Concurrency Interoperability with Objective-C
+
+* Proposal: [SE-0297](0297-concurrency-objc.md)
+* Author: [Doug Gregor](https://github.com/DougGregor)
+* Review Manager: [Chris Lattner](https://github.com/lattner)
+* Status: **Implemented (Swift 5.5)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0297-concurrency-interoperability-with-objective-c/43306)
+* Implementation: Partially available in [recent `main` snapshots](https://swift.org/download/#snapshots) behind the flag `-Xfrontend -enable-experimental-concurrency`
+
+## Table of Contents
+
+* [Introduction](#introduction)
+* [Motivation](#motivation)
+* [Proposed solution](#proposed-solution)
+* [Detailed design](#detailed-design)
+ * [Asynchronous completion-handler methods](#asynchronous-completion-handler-methods)
+ * [Defining asynchronous @objc methods in Swift](#defining-asynchronous-objc-methods-in-swift)
+ * [Actor classes](#actor-classes)
+ * [Completion handlers must be called exactly once](#completion-handlers-must-be-called-exactly-once)
+ * [Additional Objective-C attributes](#additional-objective-c-attributes)
+* [Source compatibility](#source-compatibility)
+* [Revision history](#revision-history)
+* [Future Directions](#future-directions)
+ * [NSProgress](#nsprogress)
+
+## Introduction
+
+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.
+
+For example, consider the following Objective-C API in [CloudKit](https://developer.apple.com/documentation/cloudkit/ckcontainer/1640387-fetchshareparticipantwithuserrec):
+
+```objc
+- (void)fetchShareParticipantWithUserRecordID:(CKRecordID *)userRecordID
+ completionHandler:(void (^)(CKShareParticipant * _Nullable, NSError * _Nullable))completionHandler;
+```
+
+This API is asynchronous. It delivers its result (or an error) via completion handler. The API directly translates into Swift:
+
+```swift
+func fetchShareParticipant(
+ withUserRecordID userRecordID: CKRecord.ID,
+ completionHandler: @escaping (CKShare.Participant?, Error?) -> Void
+)
+```
+
+Existing Swift code can call this API by passing a closure for the completion handler. This proposal provides an alternate Swift translation of the API into an `async` function, e.g.,
+
+```swift
+func fetchShareParticipant(
+ withUserRecordID userRecordID: CKRecord.ID
+) async throws -> CKShare.Participant
+```
+
+Swift callers can invoke `fetchShareParticipant(withUserRecordID:)` within an `await` expression:
+
+```swift
+guard let participant = try? await container.fetchShareParticipant(withUserRecordID: user) else {
+ return nil
+}
+```
+
+Swift-evolution thread: [\[Concurrency\] Interoperability with Objective-C](https://forums.swift.org/t/concurrency-interoperability-with-objective-c/41616)
+
+## Motivation
+
+On Apple platforms, Swift's tight integration with Objective-C APIs is an important part of the developer experience. There are several core features:
+
+* Objective-C classes, protocols, and methods can be used directly from Swift.
+* Swift classes can subclass Objective-C classes.
+* Swift classes can declare conformance to Objective-C protocols.
+* Swift classes, protocols, and methods can be made available to Objective-C via the `@objc` attribute.
+
+Asynchronous APIs abound in Objective-C code: the iOS 14.0 SDK includes nearly 1,000 methods that accept completion handlers. These include methods that one could call directly from Swift, methods that one would override in a Swift-defined subclass, and methods in protocols that one would conform to. Supporting these use cases in Swift's concurrency model greatly expands the reach of this new feature.
+
+## Proposed solution
+
+The proposed solution provides interoperability between Swift's concurrency constructs and Objective-C in various places. It has several inter-dependent pieces:
+
+* Translate Objective-C completion-handler methods into `async` methods in Swift.
+* Allow `async` methods defined in Swift to be `@objc`, in which case they are exported as completion-handler methods.
+* Provide Objective-C attributes to control over how completion-handler-based APIs are translated into `async` Swift functions.
+
+The detailed design section describes the specific rules and heuristics being applied. However, the best way to evaluate the overall effectiveness of the translation is to see its effect over a large number of Objective-C APIs. [This pull request](https://github.com/DougGregor/swift-concurrency-objc/pull/1) demonstrates the effect that this proposal has on the Swift translations of Objective-C APIs across the Apple iOS, macOS, tvOS, and watchOS SDKs.
+
+## Detailed design
+
+### Asynchronous completion-handler methods
+
+An Objective-C method is potentially an asynchronous completion-handler method if it meets the following requirements:
+
+* The method has a completion handler parameter, which is an Objective-C block that will receive the "result" of the asynchronous computation. It must meet the following additional constraints:
+ * It has a `void` result type.
+ * It is called exactly once along all execution paths through the implementation.
+ * If the method can deliver an error, one of the parameters of the block is of type `NSError *` that is not `_Nonnull`. A non-nil `NSError *` value typically indicates that an error occurred, although the C `swift_async` attribute can describe other conventions (discussed in the section on Objective-C attributes).
+* The method itself has a `void` result type, because all results are delivered by the completion handler block.
+
+An Objective-C method that is potentially an asynchronous completion-handler method will be translated into an `async` method when it is either annotated explicitly with an appropriate `swift_async` attribute (described in the section on Objective-C attributes) or is implicitly inferred when the following heuristics successfully identify the completion handler parameter:
+
+* If the method has a single parameter, and the suffix of the first selector piece is one of the following phrases:
+ - `WithCompletion`
+ - `WithCompletionHandler`
+ - `WithCompletionBlock`
+ - `WithReplyTo`
+ - `WithReply`
+ the sole parameter is the completion handler parameter. The matching phrase will be removed from the base name of the function when it is imported.
+* If the method has more than one parameter, the last parameter is the completion handler parameter if its selector piece or parameter name is `completion`, `withCompletion`, `completionHandler`, `withCompletionHandler`, `completionBlock`, `withCompletionBlock`, `replyTo`, `withReplyTo`, `reply`, or `replyTo`.
+* If the method has more than one parameter, and the last parameter ends with one of the suffixes from the first bullet, the last parameter is the completion handler. The text preceding the suffix is appended to the base name of the function.
+
+When the completion handler parameter is inferred, the presence of an `NSError *` parameter that is not `_Nonnull` in the completion handler block type indicates that the translated method can deliver an error.
+
+The translation of an asynchronous Objective-C completion-handler method into an `async` Swift method follows the normal translation procedure, with the following alterations:
+
+* The completion handler parameter is removed from the parameter list of the translated Swift method.
+* If the method can deliver an error, it is `throws` in addition to being `async`.
+* The parameter types of the completion handler block type are translated into the result type of the `async` method, subject to the following additional rules:
+ * If the method can deliver an error, the `NSError *` parameter is ignored.
+ * If the method can deliver an error and a given parameter has the `_Nullable_result` nullability qualifier (see the section on Objective-C attributes below), it will be imported as optional. Otherwise, it will be imported as non-optional.
+ * If there are multiple parameter types, they will be combined into a tuple type.
+
+The following [PassKit API](https://developer.apple.com/documentation/passkit/pkpasslibrary/3543357-signdata?language=objc) demonstrates how the inference rule plays out:
+
+```objc
+- (void)signData:(NSData *)signData
+withSecureElementPass:(PKSecureElementPass *)secureElementPass
+ completion:(void (^)(NSData *signedData, NSData *signature, NSError *error))completion;
+```
+
+Today, this is translated into the following completion-handler function in Swift:
+
+```swift
+@objc func sign(_ signData: Data,
+ using secureElementPass: PKSecureElementPass,
+ completion: @escaping (Data?, Data?, Error?) -> Void
+)
+```
+
+This will be translated into the following `async` function:
+
+```swift
+@objc func sign(
+ _ signData: Data,
+ using secureElementPass: PKSecureElementPass
+) async throws -> (Data, Data)
+```
+
+When the compiler sees a call to such a method, it effectively uses `withUnsafeContinuation` to form a continuation for the rest of the function, then wraps the given continuation in a closure. For example:
+
+```swift
+let (signedValue, signature) = try await passLibrary.sign(signData, using: pass)
+```
+
+becomes pseudo-code similar to
+
+```swift
+try withUnsafeContinuation { continuation in
+ passLibrary.sign(
+ signData, using: pass,
+ completionHandler: { (signedValue, signature, error) in
+ if let error = error {
+ continuation.resume(throwing: error)
+ } else {
+ continuation.resume(returning: (signedValue!, signature!))
+ }
+ }
+ )
+}
+```
+
+Additional rules are applied when translating an Objective-C method name into a Swift name of an `async` function:
+
+* If the base name of the method starts with `get`, the `get` is removed and the leading initialisms are lowercased.
+* If the base name of the method ends with `Asynchronously`, that word is removed.
+
+If the completion-handler parameter of the Objective-C method is nullable and the translated `async` method returns non-`Void`, it will be marked with the `@discardableResult` attribute. For example:
+
+```objc
+-(void)stopRecordingWithCompletionHandler:void(^ _Nullable)(RPPreviewViewController * _Nullable, NSError * _Nullable)handler;
+```
+
+will become:
+
+```swift
+@discardableResult func stopRecording() async throws -> RPPreviewViewController
+```
+
+### Defining asynchronous `@objc` methods in Swift
+
+Many Swift entities can be exposed to Objective-C via the `@objc` attribute. With an `async` Swift method, the compiler will add an appropriate completion-handler parameter to the Objective-C method it creates, using what is effectively the inverse of the transformation described in the previous section, such that the Objective-C method produced is an asynchronous Objective-C completion-handler method. For example, a method such as:
+
+```swift
+@objc func perform(operation: String) async -> Int { ... }
+```
+
+will translate into the following Objective-C method:
+
+```objc
+- (void)performWithOperation:(NSString * _Nonnull)operation
+ completionHandler:(void (^ _Nullable)(NSInteger))completionHandler;
+```
+
+The Objective-C method implementation synthesized by the compiler will create a detached task that calls the `async` Swift method `perform(operation:)` with the given string, then (if the completion handler argument is not `nil`) forwards the result to the completion handler.
+
+For an `async throws` method, the completion handler is extended with an `NSError *` parameter to indicate the error, any non-nullable pointer type parameters are made `_Nullable`, and any nullable pointer type parameters are made `_Nullable_result`. For example, given:
+
+```swift
+@objc func performDangerousTrick(operation: String) async throws -> String { ... }
+```
+
+the resulting Objective-C method will have the following signature:
+
+```objc
+- (void)performDangerousTrickWithOperation:(NSString * _Nonnull)operation
+ completionHandler:(void (^ _Nullable)(NSString * _Nullable, NSError * _Nullable))completionHandler;
+```
+
+Again, the synthesized Objective-C method implementation will create a detached task that calls the `async throws` method `performDangerousTrick(operation:)`. If the method returns normally, the `String` result will be delivered to the completion handler in the first parameter and the second parameter (`NSError *`) will be passed `nil`. If the method throws, the first parameter will be passed `nil` (which is why it has been made `_Nullable` despite being non-optional in Swift) and the second parameter will receive the error. If there are non-pointer parameters, they will be passed zero-initialized memory in the non-error arguments to provide consistent behavior for callers. This can be demonstrated with Swift pseudo-code:
+
+```swift
+// Synthesized by the compiler
+@objc func performDangerousTrick(
+ operation: String,
+ completionHandler: ((String?, Error?) -> Void)?
+) {
+ runDetached {
+ do {
+ let value = try await performDangerousTrick(operation: operation)
+ completionHandler?(value, nil)
+ } catch {
+ completionHandler?(nil, error)
+ }
+ }
+}
+```
+
+### Actor classes
+
+Actor classes can be `@objc` and will be available in Objective-C as are other classes. Actor classes require that their superclass (if there is one) also be an actor class. However, this proposal loosens that requirement slightly to allow an actor class to have `NSObject` as its superclass. This is conceptually safe because `NSObject` has no state (and its layout is effectively fixed that way), and makes it possible both for actor classes to be `@objc` and also implies conformance to `NSObjectProtocol`, which is required when conforming to a number of Objective-C protocols and is otherwise unimplementable in Swift.
+
+A member of an actor class can only be `@objc` if it is either `async` or is outside of the actor's isolation domain. Synchronous code that is within the actor's isolation domain can only be invoked on `self` (in Swift). Objective-C does not have knowledge of actor isolation, so these members are not permitted to be exposed to Objective-C. For example:
+
+```swift
+actor class MyActor {
+ @objc func synchronous() { } // error: part of actor's isolation domain
+ @objc func asynchronous() async { } // okay: asynchronous
+ @objc @actorIndependent func independent() { } // okay: actor-independent
+}
+```
+
+### Completion handlers must be called exactly once
+
+A Swift `async` function will always suspend, return, or (if it throws) produce an error. For completion-handler APIs, it is important that the completion handler block be called exactly once on all paths, including when producing an error. Failure to do so will break the semantics of the caller, either by failing to continue or by executing the same code multiple times. While this is an existing problem, widespread use of `async` with incorrectly-implemented completion-handler APIs might exacerbate the issue.
+
+Fortunately, because the compiler itself is synthesizing the block that will be passed to completion-handler APIs, it can detect both problems by introducing an extra bit of state into the synthesized block to indicate that the block has been called. If the bit is already set when the block is called, then it has been called multiple times. If the bit is not set when the block is destroyed, it has not been called at all. While this does not fix the underlying problem, it can at least detect the issue consistently at run time.
+
+### Additional Objective-C attributes
+
+The transformation of Objective-C completion-handler-based APIs to async Swift APIs could benefit from the introduction of additional annotations (in the form of attributes) to guide the process. For example:
+
+* `_Nullable_result`. Like `_Nullable`, indicates that a pointer can be null (or `nil`). `_Nullable_result` differs from `_Nullable` only for parameters to completion handler blocks. When the completion handler block's parameters are translated into the result type of an `async` method, the corresponding result will be optional.
+* `__attribute__((swift_async(...)))`. An attribute to control the translation of an asynchronous completion-handler method to an `async` function. It has several operations within the parentheses:
+ * `__attribute__((swift_async(none)))`. Disables the translation to `async`.
+ * `__attribute__((swift_async(not_swift_private, C)))`. Specifies that the method should be translated into an `async` method, using the parameter at index `C` as the completion handler parameter. The first (non-`self`) parameter has index 1.
+ * `__attribute__((swift_async(swift_private, C)))`. Specifies that the method should be translated into an `async` method that is "Swift private" (only for use when wrapping), using the parameter at index `C` as the completion handler parameter. The first (non-`self`) parameter has index 1.
+* `__attribute__((swift_attr("swift attribute")))`. A general-purpose Objective-C attribute to allow one to provide Swift attributes directly. In the context of concurrency, this allows Objective-C APIs to be annotated with a global actor (e.g., `@MainActor`).
+* `__attribute__((swift_async_name("method(param1:param2:)")))`. Specifies the Swift name that should be used for the `async` translation of the API. The name should not include an argument label for the completion handler parameter.
+* `__attribute__((swift_async_error(...)))`. An attribute to control how passing an `NSError *` into the completion handle maps into the method being `async throws`. It has several possible parameters:
+ * `__attribute__((swift_async_error(none)))`: Do not import as `throws`. The `NSError *` parameter will be considered a normal parameter.
+ * `__attribute__((swift_async_error(zero_argument, N)))`: Import as `throws`. When the Nth parameter to the completion handler is passed the integral value zero (including `false`), the async method will throw the error. The Nth parameter is removed from the result type of the translated `async` method. The first parameter is numbered `1`.
+ * `__attribute__((swift_async_error(nonzero_argument, N)))`: Import as `throws`. When the Nth parameter to the completion handler is passed a non-zero integral value (including `true`), the async method will throw the error. The Nth parameter is removed from the result type of the translated `async` method. The first parameter is numbered `1`.
+
+
+## Source compatibility
+
+Generally speaking, changes to the way in which Objective-C APIs are translated into Swift are source-breaking changes. To avoid breaking source compatibility, this proposal involves translating Objective-C asynchronous completion-handler methods as *both* their original completion-handler signatures and also with the new `async` signature. This allows existing Swift code bases to gradually adopt the `async` forms of API, rather than forcing (e.g.) an entire Swift module to adopt `async` all at once.
+
+Importing the same Objective-C API in two different ways causes some issues:
+
+* Overloading of synchronous and asynchronous APIs. Objective-C frameworks may have evolved to include both synchronous and asynchronous versions of the same API, e.g.,
+
+ ```objc
+ - (NSString *)lookupName;
+ - (void)lookupNameWithCompletionHandler:(void (^)(NSString *))completion;
+ ```
+ which will be translated into three different Swift methods:
+
+ ```swift
+ @objc func lookupName() -> String
+ @objc func lookupName(withCompletionHandler: @escaping (String) -> Void)
+ @objc func lookupName() async -> String
+ ```
+
+ The first and third signatures are identical except for being synchronous and asynchronous, respectively. The async/await design doesn't allow such overloading to be written in the same Swift module, but it can happen when translating Objective-C APIs or when importing methods from different Swift modules. The async/await design accounts for such overloading by favoring synchronous functions in synchronous contexts and asynchronous functions in asynchronous contexts. This overloading should avoid breaking source compatibility.
+
+* Another issue is when an asynchronous completion-handler method is part of an Objective-C protocol. For example, the [`NSURLSessionDataDelegate` protocol](https://developer.apple.com/documentation/foundation/nsurlsessiondatadelegate?language=objc) includes this protocol requirement:
+
+ ```objc
+ @optional
+ - (void)URLSession:(NSURLSession *)session
+ dataTask:(NSURLSessionDataTask *)dataTask
+ didReceiveResponse:(NSURLResponse *)response
+ completionHandler:(void (^)(NSURLSessionResponseDisposition disposition))completionHandler;
+ ```
+
+ Existing Swift code might implement this requirement in a conforming type using its completion-handler signature
+
+ ```swift
+ @objc
+ func urlSession(
+ _ session: URLSession,
+ dataTask: URLSessionDataTask,
+ didReceive response: URLResponse,
+ completionHandler: @escaping (URLSession.ResponseDisposition) -> Void
+ ) { ... }
+ ```
+
+ while Swift code designed to take advantage of the concurrency model would implement this requirement in a conforming type using its `async` signature
+
+ ```swift
+ @objc
+ func urlSession(
+ _ session: URLSession,
+ dataTask: URLSessionDataTask,
+ didReceive response: URLResponse
+ ) async -> URLSession.ResponseDisposition { ... }
+ ```
+
+ Implementing both requirements would produce an error (due to two Swift methods having the same selector), but under the normal Swift rules implementing only one of the requirements will also produce an error (because the other requirement is unsatisfied). Swift’s checking of protocol conformances will be extended to handle the case where multiple (imported) requirements have the same Objective-C selector: in that case, only one of them will be required to be implemented.
+
+* Overriding methods that have been translated into both completion-handler and `async` versions have a similar problem to protocol requirements: a Swift subclass can either override the completion-handler version or the `async` version, but not both. Objective-C callers will always call to the subclass version of the method, but Swift callers to the "other" signature will not unless the subclass's method is marked with `@objc dynamic`. Swift can infer that the `async` overrides of such methods are `@objc dynamic` to avoid this problem (because such `async` methods are new code). However, inferring `@objc dynamic` on existing completion-handler overrides can change the behavior of programs and break subclasses of the subclasses, so at best the compiler can warn about this situation.
+
+## Revision history
+
+* Post-review:
+ * `await try` becomes `try await` based on result of SE-0296 review
+ * Added inference of `@discardableResult` for `async` methods translated from completion-handler methods with an optional completion handler.
+* Changes in the second pitch:
+ * Removed mention of asynchronous handlers, which will be in a separate proposal.
+ * Introduced the `swift_async_error` Clang attribute to separate out "throwing" behavior from the `swift_async` attribute.
+ * Added support for "Swift private" to the `swift_async` attribute.
+ * Tuned the naming heuristics based on feedback to add (e.g) `reply`, `replyTo`, `completionBlock`, and variants.
+ * For the rare case where we match a parameter suffix, append the text prior to the suffix to the base name.
+ * Replaced the `-generateCGImagesAsynchronouslyForTimes:completionHandler:` example with one from PassKit.
+ * Added a "Future Directions" section about `NSProgress`.
+
+* Original pitch ([document](https://github.com/DougGregor/swift-evolution/blob/9b9bdfd16eb5ced390913ea170007a46eabb08eb/proposals/NNNN-concurrency-objc.md) and [forum thread](https://forums.swift.org/t/concurrency-interoperability-with-objective-c/41616)).
+
+## Future Directions
+
+### NSProgress
+
+Some Objective-C completion-handler methods return an [NSProgress](https://developer.apple.com/documentation/foundation/progress) to allow the caller to evaluate progress of the asynchronous operation. Such methods are *not* imported as `async` in this proposal, because the method does not return `void`. For example:
+
+```swift
+- (NSProgress *)doSomethingThatTakesALongTimeWithCompletionHandler:(void (^)(MyResult * _Nullable, NSError * _Nullable))completionHandler;
+```
+
+To support such methods would require some kind of integration between `NSProgress` and Swift's tasks. For example, when calling such a method, the `NSProgress` returned from such a call to be recorded in the task (say, in some kind of task-local storage). The other direction, where a Swift-defined method overrides a method, would need to extract an `NSProgress` from the task to return. Such a design is out of scope for this proposal, but could be introduced at some later point.
diff --git a/proposals/0298-asyncsequence.md b/proposals/0298-asyncsequence.md
new file mode 100644
index 0000000000..d0899264df
--- /dev/null
+++ b/proposals/0298-asyncsequence.md
@@ -0,0 +1,362 @@
+# Async/Await: Sequences
+
+* Proposal: [SE-0298](0298-asyncsequence.md)
+* Authors: [Tony Parker](https://github.com/parkera), [Philippe Hausler](https://github.com/phausler)
+* Review Manager: [Doug Gregor](https://github.com/DougGregor)
+* Status: **Implemented (Swift 5.5)**
+* Implementation: [apple/swift#35224](https://github.com/apple/swift/pull/35224)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0298-async-await-sequences/44231)
+* Revision: Based on [forum discussion](https://forums.swift.org/t/pitch-clarify-end-of-iteration-behavior-for-asyncsequence/45548)
+
+## Introduction
+
+Swift's [async/await](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0296-async-await.md) 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.
+
+This proposal is composed of the following pieces:
+
+1. A standard library definition of a protocol that represents an asynchronous sequence of values
+2. Compiler support to use `for...in` syntax on an asynchronous sequence of values
+3. A standard library implementation of commonly needed functions that operate on an asynchronous sequence of values
+
+## Motivation
+
+We'd like iterating over asynchronous sequences of values to be as easy as iterating over synchronous sequences of values. An example use case is iterating over the lines in a file, like this:
+
+```swift
+for try await line in myFile.lines() {
+ // Do something with each line
+}
+```
+
+Using the `for...in` syntax that Swift developers are already familiar with will reduce the barrier to entry when working with asynchronous APIs. Consistency with other Swift types and concepts is therefore one of our most important goals. The requirement of using the `await` keyword in this loop will distinguish it from synchronous sequences.
+### `for/in` Syntax
+
+To enable the use of `for in`, we must define the return type from `func lines()` to be something that the compiler understands can be iterated. Today, we have the `Sequence` protocol. Let's try to use it here:
+
+```swift
+extension URL {
+ struct Lines: Sequence { /* ... */ }
+ func lines() async -> Lines
+}
+```
+
+Unfortunately, what this function actually does is wait until *all* lines are available before returning. What we really wanted in this case was to await *each* line. While it is possible to imagine modifications to `lines` to behave differently (e.g., giving the result reference semantics), it would be better to define a new protocol to make this iteration behavior as simple as possible.
+
+```swift
+extension URL {
+ struct Lines: AsyncSequence { /* ... */ }
+ func lines() async -> Lines
+}
+```
+
+`AsyncSequence` allows for waiting on each element instead of the entire result by defining an asynchronous `next()` function on its associated iterator type.
+
+### Additional AsyncSequence functions
+
+Going one step further, let's imagine how it might look to use our new `lines` function in more places. Perhaps we want to process lines until we reach one that is greater than a certain length.
+
+```swift
+let longLine: String?
+do {
+ for try await line in myFile.lines() {
+ if line.count > 80 {
+ longLine = line
+ break
+ }
+ }
+} catch {
+ longLine = nil // file didn't exist
+}
+```
+
+Or, perhaps we actually do want to read all lines in the file before starting our processing:
+
+```swift
+var allLines: [String] = []
+do {
+ for try await line in myFile.lines() {
+ allLines.append(line)
+ }
+} catch {
+ allLines = []
+}
+```
+
+There's nothing wrong with the above code, and it must be possible for a developer to write it. However, it does seem like a lot of boilerplate for what might be a common operation. One way to solve this would be to add more functions to `URL`:
+
+```swift
+extension URL {
+ struct Lines : AsyncSequence { }
+
+ func lines() -> Lines
+ func firstLongLine() async throws -> String?
+ func collectLines() async throws -> [String]
+}
+```
+
+It doesn't take much imagination to think of other places where we may want to do similar operations, though. Therefore, we believe the best place to put these functions is instead as an extension on `AsyncSequence` itself, specified generically -- just like `Sequence`.
+
+## Proposed solution
+
+The standard library will define the following protocols:
+
+```swift
+public protocol AsyncSequence {
+ associatedtype AsyncIterator: AsyncIteratorProtocol where AsyncIterator.Element == Element
+ associatedtype Element
+ __consuming func makeAsyncIterator() -> AsyncIterator
+}
+
+public protocol AsyncIteratorProtocol {
+ associatedtype Element
+ mutating func next() async throws -> Element?
+}
+```
+
+The compiler will generate code to allow use of a `for in` loop on any type which conforms with `AsyncSequence`. The standard library will also extend the protocol to provide familiar generic algorithms. Here is an example which does not actually call an `async` function within its `next`, but shows the basic shape:
+
+```swift
+struct Counter : AsyncSequence {
+ let howHigh: Int
+
+ struct AsyncIterator : AsyncIteratorProtocol {
+ let howHigh: Int
+ var current = 1
+ mutating func next() async -> Int? {
+ // We could use the `Task` API to check for cancellation here and return early.
+ guard current <= howHigh else {
+ return nil
+ }
+
+ let result = current
+ current += 1
+ return result
+ }
+ }
+
+ func makeAsyncIterator() -> AsyncIterator {
+ return AsyncIterator(howHigh: howHigh)
+ }
+}
+```
+
+At the call site, using `Counter` would look like this:
+
+```swift
+for await i in Counter(howHigh: 3) {
+ print(i)
+}
+
+/*
+Prints the following, and finishes the loop:
+1
+2
+3
+*/
+
+
+for await i in Counter(howHigh: 3) {
+ print(i)
+ if i == 2 { break }
+}
+/*
+Prints the following:
+1
+2
+*/
+```
+
+## Detailed design
+
+Returning to our earlier example:
+
+```swift
+for try await line in myFile.lines() {
+ // Do something with each line
+}
+```
+
+The compiler will emit the equivalent of the following code:
+
+```swift
+var it = myFile.lines().makeAsyncIterator()
+while let line = try await it.next() {
+ // Do something with each line
+}
+```
+
+All of the usual rules about error handling apply. For example, this iteration must be surrounded by `do/catch`, or be inside a `throws` function to handle the error. All of the usual rules about `await` also apply. For example, this iteration must be inside a context in which calling `await` is allowed like an `async` function.
+
+### Cancellation
+
+`AsyncIteratorProtocol` types should use the cancellation primitives provided by Swift's `Task` API, part of [structured concurrency](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md). As described there, the iterator can choose how it responds to cancellation. The most common behaviors will be either throwing `CancellationError` or returning `nil` from the iterator.
+
+If an `AsyncIteratorProtocol` type has cleanup to do upon cancellation, it can do it in two places:
+
+1. After checking for cancellation using the `Task` API.
+2. In its `deinit` (if it is a class type).
+
+### Rethrows
+
+This proposal will take advantage of a separate proposal to add specialized `rethrows` conformance in a protocol, pitched [here](https://forums.swift.org/t/pitch-rethrowing-protocol-conformances/42373). With the changes proposed there for `rethrows`, it will not be required to use `try` when iterating an `AsyncSequence` which does not itself throw.
+
+The `await` is always required because the definition of the protocol is that it is always asynchronous.
+
+### End of Iteration
+
+After an `AsyncIteratorProtocol` types returns `nil` or throws an error from its `next()` method, all future calls to `next()` must return `nil`. This matches the behavior of `IteratorProtocol` types and is important, since calling an iterator's `next()` method is the only way to determine whether iteration has finished.
+
+## AsyncSequence Functions
+
+The existence of a standard `AsyncSequence` protocol allows us to write generic algorithms for any type that conforms to it. There are two categories of functions: those that return a single value (and are thus marked as `async`), and those that return a new `AsyncSequence` (and are not marked as `async` themselves).
+
+The functions that return a single value are especially interesting because they increase usability by changing a loop into a single `await` line. Functions in this category are `first`, `contains`, `min`, `max`, `reduce`, and more. Functions that return a new `AsyncSequence` include `filter`, `map`, and `compactMap`.
+
+### AsyncSequence to single value
+
+Algorithms that reduce a for loop into a single call can improve readability of code. They remove the boilerplate required to set up and iterate a loop.
+
+For example, here is the `contains` function:
+
+```swift
+extension AsyncSequence where Element : Equatable {
+ public func contains(_ value: Element) async rethrows -> Bool
+}
+```
+
+With this extension, our "first long line" example from earlier becomes simply:
+
+```swift
+let first = try? await myFile.lines().first(where: { $0.count > 80 })
+```
+
+Or, if the sequence should be processed asynchronously and used later:
+
+```swift
+async let first = myFile.lines().first(where: { $0.count > 80 })
+
+// later
+
+warnAboutLongLine(try? await first)
+```
+
+The following functions will be added to `AsyncSequence`:
+
+| Function | Note |
+| - | - |
+| `contains(_ value: Element) async rethrows -> Bool` | Requires `Equatable` element |
+| `contains(where: (Element) async throws -> Bool) async rethrows -> Bool` | The `async` on the closure allows optional async behavior, but does not require it |
+| `allSatisfy(_ predicate: (Element) async throws -> Bool) async rethrows -> Bool` | |
+| `first(where: (Element) async throws -> Bool) async rethrows -> Element?` | |
+| `min() async rethrows -> Element?` | Requires `Comparable` element |
+| `min(by: (Element, Element) async throws -> Bool) async rethrows -> Element?` | |
+| `max() async rethrows -> Element?` | Requires `Comparable` element |
+| `max(by: (Element, Element) async throws -> Bool) async rethrows -> Element?` | |
+| `reduce(_ initialResult: T, _ nextPartialResult: (T, Element) async throws -> T) async rethrows -> T` | |
+| `reduce(into initialResult: T, _ updateAccumulatingResult: (inout T, Element) async throws -> ()) async rethrows -> T` | |
+
+### AsyncSequence to AsyncSequence
+
+These functions on `AsyncSequence` return a result which is itself an `AsyncSequence`. Due to the asynchronous nature of `AsyncSequence`, the behavior is similar in many ways to the existing `Lazy` types in the standard library. Calling these functions does not eagerly `await` the next value in the sequence, leaving it up to the caller to decide when to start that work by simply starting iteration when they are ready.
+
+As an example, let's look at `map`:
+
+```swift
+extension AsyncSequence {
+ public func map(
+ _ transform: @escaping (Element) async throws -> Transformed
+ ) -> AsyncMapSequence
+}
+
+public struct AsyncMapSequence: AsyncSequence {
+ public let upstream: Upstream
+ public let transform: (Upstream.Element) async throws -> Transformed
+ public struct Iterator : AsyncIterator {
+ public mutating func next() async rethrows -> Transformed?
+ }
+}
+```
+
+For each of these functions, we first define a type which conforms with the `AsyncSequence` protocol. The name is modeled after existing standard library `Sequence` types like `LazyDropWhileCollection` and `LazyMapSequence`. Then, we add a function in an extension on `AsyncSequence` which creates the new type (using `self` as the `upstream`) and returns it.
+
+| Function |
+| - |
+| `map(_ transform: (Element) async throws -> T) -> AsyncMapSequence` |
+| `compactMap(_ transform: (Element) async throws -> T?) -> AsyncCompactMapSequence` |
+| `flatMap(_ transform: (Element) async throws -> SegmentOfResult) async rethrows -> AsyncFlatMapSequence` |
+| `drop(while: (Element) async throws -> Bool) async rethrows -> AsyncDropWhileSequence` |
+| `dropFirst(_ n: Int) async rethrows -> AsyncDropFirstSequence` |
+| `prefix(while: (Element) async throws -> Bool) async rethrows -> AsyncPrefixWhileSequence` |
+| `prefix(_ n: Int) async rethrows -> AsyncPrefixSequence` |
+| `filter(_ predicate: (Element) async throws -> Bool) async rethrows -> AsyncFilterSequence` |
+
+## Future Proposals
+
+The following topics are things we consider important and worth discussion in future proposals:
+
+### Additional `AsyncSequence` functions
+
+We've aimed for parity with the most relevant `Sequence` functions. There may be others that are worth adding in a future proposal.
+
+API which uses a time argument must be coordinated with the discussion about `Executor` as part of the [structured concurrency proposal](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md).
+
+We would like a `first` property, but properties cannot currently be `async` or `throws`. Discussions are ongoing about adding a capability to the language to allow effects on properties. If those features become part of Swift then we should add a `first` property to `AsyncSequence`.
+
+### AsyncSequence Builder
+
+In the standard library we have not only the `Sequence` and `Collection` protocols, but concrete types which adopt them (for example, `Array`). We will need a similar API for `AsyncSequence` that makes it easy to construct a concrete instance when needed, without declaring a new type and adding protocol conformance.
+
+## Source compatibility
+
+This new functionality will be source compatible with existing Swift.
+
+## Effect on ABI stability
+
+This change is additive to the ABI.
+
+## Effect on API resilience
+
+This change is additive to API.
+
+## Alternatives considered
+
+### Explicit Cancellation
+
+An earlier version of this proposal included an explicit `cancel` function. We removed it for the following reasons:
+
+1. Reducing the requirements of implementing `AsyncIteratorProtocol` makes it simpler to use and easier to understand. The rules about when `cancel` would be called, while straightforward, would nevertheless be one additional thing for Swift developers to learn.
+2. The structured concurrency proposal already includes a definition of cancellation that works well for `AsyncSequence`. We should consider the overall behavior of cancellation for asynchronous code as one concept.
+
+### Asynchronous Cancellation
+
+If we used explicit cancellation, the `cancel()` function on the iterator could be marked as `async`. However, this means that the implicit cancellation done when leaving a `for/in` loop would require an implicit `await` -- something we think is probably too much to hide from the developer. Most cancellation behavior is going to be as simple as setting a flag to check later, so we leave it as a synchronous function and encourage adopters to make cancellation fast and non-blocking.
+
+### Opaque Types
+
+Each `AsyncSequence`-to-`AsyncSequence` algorithm will define its own concrete type. We could attempt to hide these details behind a general purpose type eraser. We believe leaving the types exposed gives us (and the compiler) more optimization opportunities. A great future enhancement would be for the language to support `some AsyncSequence where Element=...`-style syntax, allowing hiding of concrete `AsyncSequence` types at API boundaries.
+
+### Reusing Sequence
+
+If the language supported a `reasync` concept, then it seems plausible that the `AsyncSequence` and `Sequence` APIs could be merged. However, we believe it is still valuable to consider these as two different types. The added complexity of a time dimension in asynchronous code means that some functions need more configuration options or more complex implementations. Some algorithms that are useful on asynchronous sequences are not meaningful on synchronous ones. We prefer not to complicate the API surface of the synchronous collection types in these cases.
+
+### Naming
+
+The names of the concrete `AsyncSequence` types is designed to mirror existing standard library API like `LazyMapSequence`. Another option is to introduce a new pattern with an empty enum or other namespacing mechanism.
+
+We considered `AsyncGenerator` but would prefer to leave the `Generator` name for future language enhancements. `Stream` is a type in Foundation, so we did not reuse it here to avoid confusion.
+
+### `await in`
+
+We considered a shorter syntax of `await...in`. However, since the behavior here is fundamentally a loop, we feel it is important to use the existing `for` keyword as a strong signal of intent to readers of the code. Although there are a lot of keywords, each one has purpose and meaning to readers of the code.
+
+### Add APIs to iterator instead of sequence
+
+We discussed applying the fundamental API (`map`, `reduce`, etc.) to `AsyncIteratorProtocol` instead of `AsyncSequence`. There has been a long-standing (albeit deliberate) ambiguity in the `Sequence` API -- is it supposed to be single-pass or multi-pass? This new kind of iterator & sequence could provide an opportunity to define this more concretely.
+
+While it is tempting to use this new API to right past wrongs, we maintain that the high level goal of consistency with existing Swift concepts is more important.
+
+For example, `for...in` cannot be used on an `IteratorProtocol` -- only a `Sequence`. If we chose to make `AsyncIteratorProtocol` use `for...in` as described here, that leaves us with the choice of either introducing an inconsistency between `AsyncIteratorProtocol` and `IteratorProtocol` or giving up on the familiar `for...in` syntax. Even if we decided to add `for...in` to `IteratorProtocol`, it would still be inconsistent because we would be required to leave `for...in` syntax on the existing `Sequence`.
+
+Another point in favor of consistency is that implementing an `AsyncSequence` should feel familiar to anyone who knows how to implement a `Sequence`.
+
+We are hoping for widespread adoption of the protocol in API which would normally have instead used a `Notification`, informational delegate pattern, or multi-callback closure argument. In many of these cases we feel like the API should return the 'factory type' (an `AsyncSequence`) so that it can be iterated again. It will still be up to the caller to be aware of any underlying cost of performing that operation, as with iteration of any `Sequence` today.
diff --git a/proposals/0299-extend-generic-static-member-lookup.md b/proposals/0299-extend-generic-static-member-lookup.md
new file mode 100644
index 0000000000..89813ef0b8
--- /dev/null
+++ b/proposals/0299-extend-generic-static-member-lookup.md
@@ -0,0 +1,281 @@
+# Extending Static Member Lookup in Generic Contexts
+
+* Proposal: [SE-0299](0299-extend-generic-static-member-lookup.md)
+* Authors: [Pavel Yaskevich](https://github.com/xedin), [Sam Lazarus](https://github.com/sl), [Matt Ricketson](https://github.com/ricketson)
+* Review Manager: [Joe Groff](https://github.com/jckarter)
+* Status: **Implemented (Swift 5.5)**
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0299-extending-static-member-lookup-in-generic-contexts/45238)
+* Implementation: [apple/swift#34523](https://github.com/apple/swift/pull/34523)
+* Decision Notes: [First return for revision](https://forums.swift.org/t/returned-for-revision-se-0299-extending-static-member-lookup-in-generic-contexts/44466), [First review thread](https://forums.swift.org/t/se-0299-extending-static-member-lookup-in-generic-contexts/43958)
+* Previous Revision: [1](https://github.com/swiftlang/swift-evolution/blob/4dd3a9c85195185ab7ad99c468732c5b568d51ac/proposals/0299-extend-generic-static-member-lookup.md)
+
+## Introduction
+
+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-evolution thread: [Extending Static Member Lookup in Generic Contexts](https://forums.swift.org/t/proposal-static-member-lookup-on-protocol-metatypes/41946)
+
+## Motivation
+
+### Background
+
+Today, Swift supports static member lookup on concrete types. For example, SwiftUI extends types like `Font` and `Color` with pre-defined, commonly-used values as static properties:
+
+```swift
+extension Font {
+ public static let headline: Font
+ public static let subheadline: Font
+ public static let body: Font
+ ...
+}
+
+extension Color {
+ public static let red: Color
+ public static let green: Color
+ public static let blue: Color
+ ...
+}
+```
+
+SwiftUI offers view modifiers that accept instances of `Font` and `Color`, including the static values offered above:
+
+```swift
+VStack {
+ Text(item.title)
+ .font(Font.headline)
+ .foregroundColor(Color.primary)
+ Text(item.subtitle)
+ .font(Font.subheadline)
+ .foregroundColor(Color.secondary)
+}
+```
+
+However, this example shows how “fully-qualified” accessors, include the `Font` and `Color` type names when accessing their static properties, are often redundant in context: we know from the `font()` and `foregroundColor()` modifier names that we’re expecting fonts and colors, respectively, so the type names just add unnecessary repetition.
+
+Fortunately, Swift’s static member lookup on concrete types is clever enough that it can infer the base type from context, allowing for the use of enum-like “leading dot syntax” (including a good autocomplete experience). This improves legibility, but without loss of clarity:
+
+```swift
+VStack {
+ Text(item.title)
+ .font(.headline)
+ .foregroundColor(.primary)
+ Text(item.subtitle)
+ .font(.subheadline)
+ .foregroundColor(.secondary)
+}
+```
+
+### The Problem
+
+**Swift static member lookup is not currently supported for members of protocols in generic functions, so there is no way to use leading dot syntax at a generic call site.** For example, SwiftUI defines a `toggleStyle` view modifier like so:
+
+```swift
+extension View {
+ public func toggleStyle(_ style: S) -> some View
+}
+```
+
+which accepts instances of the `ToggleStyle` protocol, e.g.
+
+```swift
+public protocol ToggleStyle {
+ associatedtype Body: View
+ func makeBody(configuration: Configuration) -> Body
+}
+
+public struct DefaultToggleStyle: ToggleStyle { ... }
+public struct SwitchToggleStyle: ToggleStyle { ... }
+public struct CheckboxToggleStyle: ToggleStyle { ... }
+```
+
+Today, SwiftUI apps must write the full name of the concrete conformers to `ToggleStyle` when using the `toggleStyle` modifier:
+
+```swift
+Toggle("Wi-Fi", isOn: $isWiFiEnabled)
+ .toggleStyle(SwitchToggleStyle())
+```
+
+However, this approach has a few downsides:
+
+* **Repetitive:** Only the “Switch” component of the style name is important, since we already know that the modifier expects a type of `ToggleStyle`.
+* **Poor discoverability:** There is no autocomplete support to expose the available `ToggleStyle` types to choose from, so you have to know them in advance.
+
+These downsides are impossible to avoid for generic parameters like above, which discourages generalizing functions. API designers should not have to choose between good design and easy-to-read code.
+
+Instead, we could ideally support leading dot syntax for generic types with known protocol conformances, allowing syntax like this:
+
+```swift
+Toggle("Wi-Fi", isOn: $isWiFiEnabled)
+ .toggleStyle(.switch)
+```
+
+### Existing Workarounds
+
+There are ways of achieving the desired syntax today without changing the language, however they are often too complex and too confusing for API clients.
+
+When SwiftUI was still in beta, it included one such workaround in the form of the `StaticMember` type:
+
+```swift
+// Rejected SwiftUI APIs:
+
+public protocol ToggleStyle {
+ // ...
+ typealias Member = StaticMember
+}
+
+extension View {
+ public func toggleStyle(_ style: S.Member) -> some View
+}
+
+public struct StaticMember {
+ public var base: Base
+ public init(_ base: Base)
+}
+
+extension StaticMember where Base: ToggleStyle {
+ public static var `default`: StaticMember { get }
+ public static var `switch`: StaticMember { get }
+ public static var checkbox: StaticMember { get }
+}
+
+// Leading dot syntax (using rejected workaround):
+
+Toggle("Wi-Fi", isOn: $isWiFiEnabled)
+ .toggleStyle(.switch)
+```
+
+However, `StaticMember` *serves no purpose* outside of achieving a more ideal syntax elsewhere. Its inclusion is hard to comprehend for anyone looking at the public facing API, as the type itself is decoupled from its actual purpose. SwiftUI removed `StaticMember` before exiting beta for exactly that reason: developers were commonly confused by its existence, declaration complexity, and usage within the framework.
+
+In a [prior pitch](https://forums.swift.org/t/protocol-metatype-extensions-to-better-support-swiftui/25469), [Matthew Johnson](https://forums.swift.org/u/anandabits) rightly called out how framework-specific solutions like `StaticMember` are not ideal: this is a general-purpose problem, which demands a general-purpose solution, not framework-specific solutions like `StaticMember`.
+
+## Proposed solution
+
+We propose *partially* lifting the current limitation placed on referencing of static members from protocol metatypes in order to improve call site ergonomics of the language and make leading dot syntax behave consistently for all possible base types.
+
+More specifically, we propose allowing static members declared in extensions of protocols to be referenced by leading dot syntax if the declaring extension or member itself constrains `Self` to be a concrete type.
+
+The scope of this proposal is limited by design: partially lifting this restriction is an incremental step forward that doesn’t require making significant changes to the implementation of protocols, but also does not foreclose making further improvements in the future such as generally supporting protocol metatype extensions (more on this in *Alternatives Considered*, below).
+
+## Detailed design
+
+The type-checker is able to infer any protocol conformance requirements placed on a particular argument from the call site of a generic function. In our previous example, the `toggleStyle` function requires its argument conform to `ToggleStyle`. Based on that information, the type-checker should be able to resolve a base type for a leading dot syntax argument as a type which conforms to the `ToggleStyle` protocol. It can’t simply use the type `ToggleStyle` because only types conforming to a protocol can provide a witness method to reference. To discover such a type and produce a well-formed reference there are two options:
+
+* Do a global lookup for any type which conforms to the given protocol and use it as a base;
+* Require that protocol extension declaring static member(s) or member itself (i.e. generic function/subscript) has 'Self' bound to a concrete type via a same-type generic requirement that would be used to provide a witness for the reference.
+
+The second option is a much better choice that avoids having to do a global lookup and conformance checking and is consistent with the semantics of leading dot syntax, namely, the requirement that result and base types of the chain have to be convertible. This leads to a new rule: if member either binds 'Self' directly (via same-type generic requirement), or is declared in a protocol extension that has `Self` bound to a concrete type, it should be possible to reference such a member on a protocol metatype, using leading dot syntax, by implicitly replacing the protocol with a conforming type referred by `Self`.
+
+This approach works well for references without an explicit base, let’s consider an example:
+
+```swift
+// Existing SwiftUI APIs:
+
+public protocol ToggleStyle { ... }
+
+public struct DefaultToggleStyle: ToggleStyle { ... }
+public struct SwitchToggleStyle: ToggleStyle { ... }
+public struct CheckboxToggleStyle: ToggleStyle { ... }
+
+extension View {
+ public func toggleStyle(_ style: S) -> some View
+}
+
+// Possible SwiftUI APIs:
+
+extension ToggleStyle where Self == DefaultToggleStyle {
+ public static var `default`: Self { .init() }
+}
+
+extension ToggleStyle where Self == SwitchToggleStyle {
+ public static var `switch`: Self { .init() }
+}
+
+extension ToggleStyle where Self == CheckboxToggleStyle {
+ public static var checkbox: Self { .init() }
+}
+
+// Leading dot syntax (using proposed solution):
+
+Toggle("Wi-Fi", isOn: $isWiFiEnabled)
+ .toggleStyle(.switch)
+```
+
+In the case of `.toggleStyle(.switch)`, the reference to the member `.switch` is re-written to be `SwitchToggleStyle.switch` in the type-checked AST.
+
+Note that declaring members this way pollutes the namespace of each concrete type by creating members like `DefaultToggleStyle.default`, but we believe this is an acceptable trade-off to improve call site ergonomics.
+
+It's also possible to bind `Self` to a type with generic parameters:
+
+```swift
+public struct CustomToggleStyle: ToggleStyle {
+ ...
+}
+
+extension ToggleStyle {
+ public static func custom(_: T) -> Self where Self == CustomToggleStyle {
+ ...
+ }
+}
+
+Toggle("Wi-Fi", isOn: $isWiFiEnabled)
+ .toggleStyle(.custom(42)) // base type is inferred to be `CustomToggleStyle` based on the argument type.
+```
+
+To make this work the type-checker would attempt to infer protocol conformance requirements from context, e.g. the call site of a generic function (in this case there is only one such requirement - the protocol `ToggleStyle`), and propagate them to the type variable representing the implicit base type of the chain. If there is no other contextual information available, e.g. the result type couldn’t be inferred to some concrete type, the type-checker would attempt to bind base to the type of the inferred protocol requirement.
+
+Member lookup filtering is adjusted to find static members declared in extension of a protocol metatype. Type-checker would then attempt to find innermost generic signature (either signature of context or itself, if it's some kind of a generic function) and make sure 'Self' parameter of a protocol is bound to a concrete type before accepting the member. When a reference to such a member is considered in expression context, type-checker would replace implicit base type with the concrete type referred by `Self` to form a valid reference to a static member.
+
+## Source compatibility
+
+This is a purely additive change and does not have any effect on source compatibility.
+
+
+
+## Effect on ABI stability
+
+This change is frontend only and would not impact ABI.
+
+
+
+## Effect on API resilience
+
+This is not an API-level change and would not impact resilience.
+
+
+## Alternatives considered
+
+### Allow declaring static members directly on protocol metatypes
+
+There have been multiple discussions on this topic on the Swift forums. The most recent one being [a post from Matthew Johnson](https://forums.swift.org/t/protocol-metatype-extensions-to-better-support-swiftui/25469), which suggests adding a special syntax to the language to enable static member references on protocol metatypes. After investigating this direction we determined that supporting this would require significant changes to the implementation of protocols.
+
+Due to its narrow scope, the proposed design is simpler and does not require any syntax changes, while still satisfying all the intended use cases. We stress that this is an incremental improvement, which should not impede our ability to support protocol metatype extensions in the future.
+
+One concrete concern is whether the kind of static member lookup proposed here would be ambiguous with static member lookup on a hypothetical future protocol metatype property. We do not believe it would be, since lookup could be prioritized on the metatype over conforming types. Further, these kinds of namespace and lookup conflicts would likely need to be addressed in a future metatype extension proposal regardless of whether the lookup extension proposed here is accepted or not.
+
+### Allow leading dot syntax for any extensions on protocol metatypes where the return type can be used as the base type
+
+While technically feasible (as the compiler can use the concrete return type as the base type of the expression), this approach leads to the pollution of the protocols namespace. Consider the SwiftUI use case with this approach. The following use case would be valid as the types of the `default`, `switch` and `checkbox` static members all conform to `ToggleStyle`:
+
+```swift
+extension ToggleStyle {
+ public static var `default`: DefaultToggleStyle { .init() }
+ public static var `switch`: SwitchToggleStyle { .init() }
+ public static var checkbox: CheckboxToggleStyle { .init() }
+}
+```
+
+This unfortunately leads to all of the following being valid:
+
+```swift
+DefaultToggleStyle.checkbox
+SwitchToggleStyle.default
+CheckboxToggleStyle.switch
+// and so on and so forth
+```
+
+# Revision History
+
+The [initial revision of this proposal](https://github.com/swiftlang/swift-evolution/blob/4dd3a9c85195185ab7ad99c468732c5b568d51ac/proposals/0299-extend-generic-static-member-lookup.md)
+allowed contextual member lookup to find protocol extension members without
+the `Self` requirement, but as noted above, the Core Team rejected this ability
+because of the potential for namespace pollution.
diff --git a/proposals/0300-continuation.md b/proposals/0300-continuation.md
new file mode 100644
index 0000000000..e6574abde4
--- /dev/null
+++ b/proposals/0300-continuation.md
@@ -0,0 +1,483 @@
+# Continuations for interfacing async tasks with synchronous code
+
+* Proposal: [SE-0300](0300-continuation.md)
+* Authors: [John McCall](https://github.com/rjmccall), [Joe Groff](https://github.com/jckarter), [Doug Gregor](https://github.com/DougGregor), [Konrad Malawski](https://github.com/ktoso)
+* Review Manager: [Ben Cohen](https://github.com/airspeedswift)
+* Status: **Implemented (Swift 5.5)**
+* Previous Revisions: [1](https://github.com/swiftlang/swift-evolution/blob/5f79481244329ec2860951c0c49c101aef5069e7/proposals/0300-continuation.md), [2](https://github.com/swiftlang/swift-evolution/blob/61c788cdb9674c99fc8731b49056cebcb5497edd/proposals/0300-continuation.md)
+
+## Introduction
+
+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.
+
+Swift-evolution thread:
+
+- [Structured concurrency](https://forums.swift.org/t/concurrency-structured-concurrency/41622)
+- [Continuations for interfacing async tasks with synchronous code](https://forums.swift.org/t/concurrency-continuations-for-interfacing-async-tasks-with-synchronous-code/43619)
+
+## Motivation
+
+Swift APIs often provide asynchronous code execution by way of a callback. This
+may occur either because the code itself was written prior to the introduction
+of async/await, or (more interestingly in the long term) because it ties in
+with some other system that is primarily event-driven. In such cases, one may
+want to provide an async interface to clients while using callbacks internally.
+In these cases, the calling async task needs to be able to suspend itself,
+while providing a mechanism for the event-driven synchronous system to resume
+it in response to an event.
+
+## Proposed solution
+
+The library will provide APIs to get a **continuation** for the current
+asynchronous task. Getting the task's continuation suspends the task, and
+produces a value that synchronous code can then use a handle to resume the
+task. Given a completion callback based API like:
+
+```swift
+func beginOperation(completion: (OperationResult) -> Void)
+```
+
+we can turn it into an `async` interface by suspending the task and using its
+continuation to resume it when the callback is invoked, turning the argument
+passed into the callback into the normal return value of the async function:
+
+```swift
+func operation() async -> OperationResult {
+ // Suspend the current task, and pass its continuation into a closure
+ // that executes immediately
+ return await withUnsafeContinuation { continuation in
+ // Invoke the synchronous callback-based API...
+ beginOperation(completion: { result in
+ // ...and resume the continuation when the callback is invoked
+ continuation.resume(returning: result)
+ })
+ }
+}
+```
+
+## Detailed design
+
+### Raw unsafe continuations
+
+The library provides two functions, `withUnsafeContinuation` and
+`withUnsafeThrowingContinuation`, that allow one to call into a callback-based
+API from inside async code. Each function takes an *operation* closure,
+which is expected to call into the callback-based API. The closure
+receives a continuation instance that must be resumed by the callback,
+either to provide the result value or (in the throwing variant) the thrown
+error that becomes the result of the `withUnsafeContinuation` call when the
+async task resumes:
+
+
+```swift
+struct UnsafeContinuation {
+ func resume(returning: T)
+ func resume(throwing: E)
+ func resume(with result: Result)
+}
+
+extension UnsafeContinuation where T == Void {
+ func resume() { resume(returning: ()) }
+}
+
+extension UnsafeContinuation where E == Error {
+ // Allow covariant use of a `Result` with a stricter error type than
+ // the continuation:
+ func resume(with result: Result)
+}
+
+func withUnsafeContinuation(
+ _ operation: (UnsafeContinuation) -> ()
+) async -> T
+
+func withUnsafeThrowingContinuation(
+ _ operation: (UnsafeContinuation) throws -> ()
+) async throws -> T
+```
+
+`withUnsafe*Continuation` will run its `operation` argument immediately in the
+task's current context, passing in a *continuation* value that can be
+used to resume the task. The `operation` function must arrange for the
+continuation to be resumed at some point in the future; after the `operation`
+function returns, the task is suspended. The task must then be brought out
+of the suspended state by invoking one of the continuation's `resume` methods.
+Note that `resume` immediately returns control to the caller after transitioning
+the task out of its suspended state; the task itself does not actually resume
+execution until its executor reschedules it. The argument to
+`resume(returning:)` becomes the return value of `withUnsafe*Continuation`
+when the task resumes execution.
+`resume(throwing:)` can be used instead to make the task resume by propagating
+the given error. As a convenience, given a `Result`, `resume(with:)` can be used
+to resume the task by returning normally or raising an error according to the
+state of the `Result`. If the `operation` raises an uncaught error before
+returning, this behaves as if the operation had invoked `resume(throwing:)` with
+the error.
+
+If the return type of `withUnsafe*Continuation` is `Void`, one must specify
+a value of `()` when calling `resume(returning:)`. Doing so produces some
+unsightly code, so `Unsafe*Continuation` has an extra member `resume()`
+that makes the function call easier to read.
+
+After invoking `withUnsafeContinuation`, exactly one `resume` method must be
+called *exactly-once* on every execution path through the program.
+`Unsafe*Continuation` is an unsafe interface, so it is undefined behavior if
+a `resume` method is invoked on the same continuation more than once. The
+task remains in the suspended state until it is resumed; if the continuation
+is discarded and never resumed, then the task will be left suspended until
+the process ends, leaking any resources it holds.
+Wrappers can provide checking for these misuses of continuations, and the
+library will provide one such wrapper, discussed below.
+
+Using the `Unsafe*Continuation` API, one may for example wrap such
+(purposefully convoluted for the sake of demonstrating the flexibility of
+the continuation API) function:
+
+```swift
+func buyVegetables(
+ shoppingList: [String],
+ // a) if all veggies were in store, this is invoked *exactly-once*
+ onGotAllVegetables: ([Vegetable]) -> (),
+
+ // b) if not all veggies were in store, invoked one by one *one or more times*
+ onGotVegetable: (Vegetable) -> (),
+ // b) if at least one onGotVegetable was called *exactly-once*
+ // this is invoked once no more veggies will be emitted
+ onNoMoreVegetables: () -> (),
+
+ // c) if no veggies _at all_ were available, this is invoked *exactly once*
+ onNoVegetablesInStore: (Error) -> ()
+)
+// returns 1 or more vegetables or throws an error
+func buyVegetables(shoppingList: [String]) async throws -> [Vegetable] {
+ try await withUnsafeThrowingContinuation { continuation in
+ var veggies: [Vegetable] = []
+
+ buyVegetables(
+ shoppingList: shoppingList,
+ onGotAllVegetables: { veggies in continuation.resume(returning: veggies) },
+ onGotVegetable: { v in veggies.append(v) },
+ onNoMoreVegetables: { continuation.resume(returning: veggies) },
+ onNoVegetablesInStore: { error in continuation.resume(throwing: error) },
+ )
+ }
+}
+
+let veggies = try await buyVegetables(shoppingList: ["onion", "bell pepper"])
+```
+
+Thanks to weaving the right continuation resume calls into the complex
+callbacks of the `buyVegetables` function, we were able to offer a much nicer
+overload of this function, allowing async code to interact with this function in
+a more natural straight-line way.
+
+### Checked continuations
+
+`Unsafe*Continuation` provides a lightweight mechanism for interfacing
+sync and async code, but it is easy to misuse, and misuse can corrupt the
+process state in dangerous ways. In order to provide additional safety and
+guidance when developing interfaces between sync and async code, the
+library will also provide a wrapper which checks for invalid use of the
+continuation:
+
+```swift
+struct CheckedContinuation {
+ func resume(returning: T)
+ func resume(throwing: E)
+ func resume(with result: Result)
+}
+
+extension CheckedContinuation where T == Void {
+ func resume()
+}
+
+extension CheckedContinuation where E == Error {
+ // Allow covariant use of a `Result` with a stricter error type than
+ // the continuation:
+ func resume(with result: Result)
+}
+
+func withCheckedContinuation(
+ _ operation: (CheckedContinuation) -> ()
+) async -> T
+
+func withCheckedThrowingContinuation(
+ _ operation: (CheckedContinuation) throws -> ()
+) async throws -> T
+```
+
+The API is intentionally identical to the `Unsafe` variants, so that code
+can switch easily between the checked and unchecked variants. For instance,
+the `buyVegetables` example above can opt into checking merely by turning
+its call of `withUnsafeThrowingContinuation` into one of `withCheckedThrowingContinuation`:
+
+```swift
+// returns 1 or more vegetables or throws an error
+func buyVegetables(shoppingList: [String]) async throws -> [Vegetable] {
+ try await withCheckedThrowingContinuation { continuation in
+ var veggies: [Vegetable] = []
+
+ buyVegetables(
+ shoppingList: shoppingList,
+ onGotAllVegetables: { veggies in continuation.resume(returning: veggies) },
+ onGotVegetable: { v in veggies.append(v) },
+ onNoMoreVegetables: { continuation.resume(returning: veggies) },
+ onNoVegetablesInStore: { error in continuation.resume(throwing: error) },
+ )
+ }
+}
+```
+
+Instead of leading to undefined behavior, `CheckedContinuation` will instead
+trap if the program attempts to resume the continuation multiple times.
+`CheckedContinuation` will also log a warning if the continuation
+is discarded without ever resuming the task, which leaves the task stuck in its
+suspended state, leaking any resources it holds. These checks happen regardless
+of the optimization level of the program.
+
+## Additional examples
+
+Continuations can be used to interface with more complex event-driven
+interfaces than callbacks as well. As long as the entirety of the process
+follows the requirement that the continuation be resumed exactly once, there
+are no other restrictions on where the continuation can be resumed. For
+instance, an `Operation` implementation can trigger resumption of a
+continuation when the operation completes:
+
+```swift
+class MyOperation: Operation {
+ let continuation: UnsafeContinuation
+ var result: OperationResult?
+
+ init(continuation: UnsafeContinuation) {
+ self.continuation = continuation
+ }
+
+ /* rest of operation populates `result`... */
+
+ override func finish() {
+ continuation.resume(returning: result!)
+ }
+}
+
+func doOperation() async -> OperationResult {
+ return await withUnsafeContinuation { continuation in
+ MyOperation(continuation: continuation).start()
+ }
+}
+```
+
+Using APIs from the [structured concurrency proposal](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0304-structured-concurrency.md),
+one can wrap up a `URLSession` in a task, allowing the task's cancellation
+to control cancellation of the session, and using a continuation to respond
+to data and error events fired by the network activity:
+
+```swift
+func download(url: URL) async throws -> Data? {
+ var urlSessionTask: URLSessionTask?
+
+ return try Task.withCancellationHandler {
+ urlSessionTask?.cancel()
+ } operation: {
+ let result: Data? = try await withUnsafeThrowingContinuation { continuation in
+ urlSessionTask = URLSession.shared.dataTask(with: url) { data, _, error in
+ if case (let cancelled as NSURLErrorCancelled)? = error {
+ continuation.resume(returning: nil)
+ } else if let error = error {
+ continuation.resume(throwing: error)
+ } else {
+ continuation.resume(returning: data)
+ }
+ }
+ urlSessionTask?.resume()
+ }
+ if let result = result {
+ return result
+ } else {
+ Task.cancel()
+ return nil
+ }
+ }
+}
+```
+
+It is also possible for wrappers around callback based APIs to respect their parent/current tasks's cancellation, as follows:
+
+```swift
+func fetch(items: Int) async throws -> [Items] {
+ let worker = ...
+ return try Task.withCancellationHandler(
+ handler: { worker?.cancel() }
+ ) {
+ return try await withUnsafeThrowingContinuation { c in
+ worker.work(
+ onNext: { value in c.resume(returning: value) },
+ onCancelled: { value in c.resume(throwing: CancellationError()) },
+ )
+ }
+ }
+}
+```
+
+If tasks were allowed to have instances, which is under discussion in the structured concurrency proposal, it would also be possible to obtain the task in which the fetch(items:) function was invoked and call isCanceled on it whenever the insides of the withUnsafeThrowingContinuation would deem it worthwhile to do so.
+
+## Alternatives considered
+
+### Name `CheckedContinuation` just `Continuation`
+
+We could position `CheckedContinuation` as the "default" API for doing
+sync/async interfacing by leaving the `Checked` word out of the name. This
+would certainly be in line with the general philosophy of Swift that safe
+interfaces are preferred, and unsafe ones used selectively where performance
+is an overriding concern. There are a couple of reasons to hesitate at doing
+this here, though:
+
+- Although the consequences of misusing `CheckedContinuation` are not as
+ severe as `UnsafeContinuation`, it still only does a best effort at checking
+ for some common misuse patterns, and it does not render the consequences of
+ continuation misuse entirely moot: dropping a continuation without resuming
+ it will still leak the un-resumed task, and attempting to resume a
+ continuation multiple times will still cause the information passed through
+ the continuation to be lost. It is still a serious programming error if
+ a `with*Continuation` operation misuses the continuation;
+ `CheckedContinuation` only helps make the error more apparent.
+- Naming a type `Continuation` now might take the "good" name away if,
+ after we have move-only types at some point in the future, we want to
+ introduce a continuation type that statically enforces the exactly-once
+ property.
+
+### Don't expose `UnsafeContinuation`
+
+One could similarly make an argument that `UnsafeContinuation` shouldn't be
+exposed at all, since the `Checked` form can always be used instead. We think
+that being able to avoid the cost of checking when interacting with
+performance-sensitive APIs is valuable, once users have validated that their
+interfaces to those APIs are correct.
+
+### Have `CheckedContinuation` trap on all misuses, or log all misuses
+
+`CheckedContinuation` is proposed to trap when the program attempts to
+resume the same continuation twice, but only log a warning if a continuation
+is abandoned without getting resumed. We think this is the right tradeoff
+for these different situations for the following reasons:
+
+- With `UnsafeContinuation`, resuming multiple times corrupts the process and
+ leaves it in an undefined state. By trapping when the task is resumed
+ multiple times, `CheckedContinuation` turns undefined behavior into a well-
+ defined trap situation. This is analogous to other checked/unchecked
+ pairings in the standard library, such as `!` vs. `unsafelyUnwrapped` for
+ `Optional`.
+- By contrast, failing to resume a continuation with `UnsafeContinuation`
+ does not corrupt the task, beyond leaking the suspended task's resources;
+ the rest of the program can continue executing normally. Furthermore,
+ the only way we can currently detect and report such a leak is by using
+ a class `deinit` in its implementation. The precise moment at which such
+ a deinit would execute is not entirely predictable because of refcounting
+ variability from ARC optimization. If `deinit` were made to trap, whether that
+ trap is executed and when could vary with optimization level, which we
+ don't think would lead to a good experience.
+
+### Expose more `Task` API on `*Continuation`, or allow a `Handle` to be recovered from a continuation
+
+The full `Task` and `Handle` API provides additional control over the task
+state to holders of the handle, particularly the ability to query and set
+cancellation state, as well as await the final result of the task, and one
+might wonder why the `*Continuation` types do not also expose this functionality.
+The role of a `Continuation` is very different from a `Handle`, in that a handle
+represents and controls the entire lifetime of the task, whereas a continuation
+only represents a *single suspension point* in the lifetime of the task.
+Furthermore, the `*Continuation` API is primarily designed to allow for
+interfacing with code outside of Swift's structured concurrency model, and
+we believe that interactions between tasks are best handled inside that model
+as much as possible.
+
+Note that `*Continuation` also does not strictly need direct support for any
+task API on itself. If, for instance, someone wants a task to cancel itself
+in response to a callback, they can achieve that by funneling a sentinel
+through the continuation's resume type, such as an Optional's `nil`:
+
+```swift
+let callbackResult: Result? = await withUnsafeContinuation { c in
+ someCallbackBasedAPI(
+ completion: { c.resume($0) },
+ cancellation: { c.resume(nil) })
+}
+
+if let result = callbackResult {
+ process(result)
+} else {
+ cancel()
+}
+```
+
+### Provide API to resume the task immediately to avoid "queue-hopping"
+
+Some APIs, in addition to taking a completion handler or delegate, also allow
+the client to control *where* that completion handler or delegate's methods are
+invoked; for instance, some APIs on Apple platforms take an argument for the
+dispatch queue the completion handler should be invoked by. In these cases,
+it would be optimal if the original API could resume the task directly on the
+dispatch queue (or whatever other scheduling mechanism, such as a thread or
+run loop) that the task would normally be resumed on by its executor. To
+enable this, we could provide a variant of `with*Continuation` that, in
+addition to providing a continuation, also provides the dispatch queue that
+the task expects to be resumed on. The `*Continuation` type in turn could
+provide an `unsafeResumeImmediately` set of APIs, which would immediately
+resume execution of the task on the current thread. This would enable something
+like this:
+
+```swift
+// Given an API that takes a queue and completion handler:
+func doThingAsynchronously(queue: DispatchQueue, completion: (ResultType) -> Void)
+
+// We could wrap it in a Swift async function like:
+func doThing() async -> ResultType {
+ await withUnsafeContinuationAndCurrentDispatchQueue { c, queue in
+ // Schedule to resume on the right queue, if we know it
+ doThingAsynchronously(queue: queue) {
+ c.unsafeResumeImmediately(returning: $0)
+ }
+ }
+}
+```
+
+However, such an API would have to be used very carefully; the programmer
+would have to be careful that `unsafeResumeImmediately` is in fact invoked
+in the correct context, and that it is safe to take over control of the
+current thread from the caller for a potentially unbounded amount of time.
+If the task is resumed in the wrong context, it will break assumptions in the
+written code as well as those made by the compiler and runtime, which will
+lead to subtle bugs that would be difficult to diagnose. We can investigate
+this as an addition to the core proposal, if "queue hopping" in continuation-
+based adapters turns out to be a performance problem in practice.
+
+## Revision history
+
+Third revision:
+
+- Replaced separate `*Continuation` and `*ThrowingContinuation` types with a
+ single `Continuation` type parameterized on the error type.
+- Added a convenience `resume()` equivalent to `resume(returning: ())` for
+ continuations with a `Void` return type.
+- Changed `with*ThrowingContinuation` to take an `operation` block that may
+ throw, and to immediately resume the task throwing the error if an uncaught
+ error propagates from the operation.
+
+Second revision:
+
+- Clarified the execution behavior of `with*Continuation` and
+ `*Continuation.resume`, namely that `with*Continuation` immediately executes
+ its operation argument in the current context before suspending the task,
+ and that `resume` immediately returns to its caller after un-suspending the
+ task, leaving the task to be scheduled by its executor.
+- Removed an unnecessary invariant on when `resume` must be invoked; it is valid
+ to invoke it exactly once at any point after the `with*Continuation` operation
+ has started executing; it does not need to run exactly when the operation
+ returns.
+- Added "future direction" discussion of a potential more advanced API that
+ could allow continuations to directly resume their task when the correct
+ dispatch queue to do so is known.
+- Added `resume()` on `Void`-returning `Continuation` types.
diff --git a/proposals/0301-package-editing-commands.md b/proposals/0301-package-editing-commands.md
new file mode 100644
index 0000000000..9778c01f1c
--- /dev/null
+++ b/proposals/0301-package-editing-commands.md
@@ -0,0 +1,179 @@
+# Package Editor Commands
+
+* Proposal: [SE-0301](0301-package-editing-commands.md)
+* Authors: [Owen Voorhees](https://github.com/owenv)
+* Review Manager: [Tom Doron](https://github.com/tomerd)
+* Status: **Implemented (Swift 6.0)**
+* Implementation: [apple/swift-package-manager#3034](https://github.com/apple/swift-package-manager/pull/3034)
+* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modification-se-0301-package-editor-commands/45069)
+
+## Introduction
+
+Because Swift package manifests are written in Swift using the PackageDescription API, it is difficult to automate common tasks like adding a new product, target, or dependency. This proposal introduces new `swift package` subcommands to perform some common editing tasks which can streamline users' workflows and enable new higher-level tools.
+
+Forums Discussion: https://forums.swift.org/t/pitch-package-editor-commands/42224/
+
+## Motivation
+
+There are a number of reasons someone might want to make changes to a package using a CLI or library interface instead of editing a manifest by hand:
+
+- In some situations, it's less error-prone than editing the manifest manually. Package authors could provide a one line command in their README to easily integrate the latest version as a dependency.
+- Because more of the process is automated, users would no longer need to remember details of the package layout convention, like which files and folders they need to create when adding a new library target.
+- Using libSwiftPM, IDEs could offer to update the manifest automatically when the user tries to import a missing dependency or create a new target.
+- Users could add packages from their package collections as dependencies by name instead of URL
+
+Additionally, many other package managers offer similar features:
+- npm's [`npm install`](https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file#adding-dependencies-to-a-packagejson-file-from-the-command-line) command for adding dependencies to its `package.json`
+- Tools like [cargo-edit](https://github.com/killercup/cargo-edit) for editing the `cargo.toml` format used by Rust
+- Elm's [`elm install`](https://elmprogramming.com/elm-install.html) command for adding dependencies to `elm.json`
+
+## Proposed solution
+
+This proposal introduces three new `swift package` subcommands: `add-product`, `add-target`, and `add-dependency`, which edit the manifest of the current package. Together, these encompass many of the most common editing operations performed by users when working on a package.
+
+## Detailed design
+
+### New Commands
+
+The following subcommands will be added to `swift package`:
+
+`swift package add-product [--type ] [--targets ]`
+
+- **name**: The name of the new product.
+- **type**: _executable_, _library_, _static-library_, or _dynamic-library_. If unspecified, this will default to _library_.
+- **targets**: A space separated list of target names to to add to the new product.
+***
+`swift package add-target [--type ] [--no-test-target] [--dependencies ] [--url ] [--path ] [--checksum ]`
+- **name**: The name of the new target.
+- **type**: _library_, _executable_, _test_, or _binary_. If unspecified, this will default to _library_. Adding system library targets will not be supported by the initial version of the CLI due to their often complex configuration requirements.
+- **--no-test-target**: By default, a test target is added for each library target unless this flag is present.
+- **dependencies**: A space separated list of target dependency names.
+- **url/path**: The URL for a remote binary target or path for a local one.
+- **checksum**: The checksum for a remote binary target.
+
+In addition to editing the manifest, the add-target command will create the appropriate `Sources` or `Tests` subdirectories for new targets.
+***
+`swift package add-dependency [--exact ] [--revision ] [--branch ] [--from ] [--up-to-next-minor-from ]`
+- **dependency**: This may be the URL of a remote package, the path to a local package, or the name of a package in one of the user's package collections.
+
+The following options can be used to specify a package dependency requirement:
+- **--exact **: Specifies a `.exact()` requirement in the manifest.
+- **--revision **: Specifies a `.revision(