Merge branch 'swiftlang:main' into patch-1

Author: amritpan

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Welcome to the Swift community! 
 
-Contributions to Swift are welcomed and encouraged! Please see the [Contributing to Swift guide](swift.org/contributing) and check out the [structure of the community](https://www.swift.org/community/#community-structure).
+Contributions to Swift are welcomed and encouraged! Please see the [Contributing to Swift guide](https://www.swift.org/contributing/) and check out the [structure of the community](https://www.swift.org/community/#community-structure).
 
 To be a truly great community, Swift needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.
 

proposals/0381-task-group-discard-results.md

@@ -5,14 +5,12 @@
 * Review Manager: [Doug Gregor](https://github.com/DougGregor)
 * Status: **Implemented (Swift 5.9)**
 * Implementation: [apple/swift#62361](https://github.com/apple/swift/pull/62361)
-* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0381-discardingtaskgroups/62615)
+* Review: ([pitch](https://forums.swift.org/t/pitch-task-pools/61703)) ([review](https://forums.swift.org/t/se-0381-discardresults-for-taskgroups/62072)) ([acceptance](https://forums.swift.org/t/accepted-se-0381-discardingtaskgroups/62615))
 
 ### Introduction
 
 We propose to introduce a new type of structured concurrency task group:  `Discarding[Throwing]TaskGroup`. This type of group is similar to `TaskGroup` however it discards results of its child tasks immediately. It is specialized for potentially never-ending task groups, such as top-level loops of http or other kinds of rpc servers.
 
-Pitch thread: [Task Pools](https://forums.swift.org/t/pitch-task-pools/61703).
-
 ## Motivation
 
 Task groups are the building block of structured concurrency, allowing for the Swift runtime to relate groups of tasks together. This enables powerful features such as automatic cancellation propagation, correctly propagating errors, and ensuring well-defined lifetimes, as well as providing diagnostic information to programming tools.

proposals/0414-region-based-isolation.md

@@ -32,7 +32,7 @@ point of transfer.
 [SE-0302](0302-concurrent-value-and-concurrent-closures.md) states
 that non-`Sendable` values cannot be passed across isolation boundaries. The
 following code demonstrates a `Sendable` violation when passing a
-newly-constructed value into an actor-isolated function:
+newly-initialized value into an actor-isolated function:
 
 ```swift
 // Not Sendable
@@ -58,9 +58,9 @@ func openNewAccount(name: String, initialBalance: Double) async {
 
 This is overly conservative; the program is safe because:
 
-* `client` does not have access to any non-`Sendable` state from its constructor
+* `client` does not have access to any non-`Sendable` state from its initializer
   parameters since Strings and Doubles are `Sendable`.
-* `client` just being constructed implies that `client` cannot have any uses
+* `client` just being initialized implies that `client` cannot have any uses
   outside of `openNewAccount`.
 * `client` is not used within `openNewAccount` beyond `addClient`.
 
@@ -223,7 +223,7 @@ precise regions.
 
 Now lets apply these rules to some specific examples in Swift code:
 
-* **Initializing a let or var binding**. ``let y = x, var y = x``. Initializing
+* **Initializing a `let` or `var` binding**. ``let y = x, var y = x``. Initializing
   a let or var binding `y` with `x` results in `y` being in the same region as
   `x`. This follows from rule `(2)` since formally a copy is equivalent to calling a
   function that accepts `x` and returns a copy of `x`.
@@ -243,7 +243,7 @@ Now lets apply these rules to some specific examples in Swift code:
   change program semantics. A valid program must still obey the no-reuse
   constraints of `consume`.
 
-* **Assigning a var binding**. ``y = x``. Assigning a var binding `y` with `x`
+* **Assigning a `var` binding**. ``y = x``. Assigning a var binding `y` with `x`
   results in `y` being in the same region as `x`. If `y` is not captured by
   reference in a closure, then `y`'s previous assigned region is forgotten due
   to `(3)(b)`:
@@ -1723,9 +1723,9 @@ resulting in a race against a write in the closure.
 ## Source compatibility
 
 Region-based isolation opens up a new data-race safety hole when using APIs
-change the static isolation in the implementation of a `nonisolated` funciton,
+change the static isolation in the implementation of a `nonisolated` function,
 such as `assumeIsolated`, because values can become referenced by actor-isolated
-state without any indication in the funciton signature:
+state without any indication in the function signature:
 
 ```swift
 class NonSendable {}
@@ -1887,7 +1887,7 @@ func example(_ x: NonSendable) async -> NonSendable? {
 }
 ```
 
-In the above, the result of `example` is a newly constructed value that has no
+In the above, the result of `example` is a newly initialized value that has no
 data dependence on the parameter `x`, but as laid out in this proposal, we
 cannot express this. We propose the addition of a new function parameter
 modifier called `returnsIsolated` that causes callers to treat the result of a
@@ -2034,7 +2034,7 @@ also be ascertained by just reading the source.
 
 ## Acknowledgments
 
-This proposal is based on work from the PLDI 2022 paper (A Flexible Type System for Fearless Concurrency)[https://www.cs.cornell.edu/andru/papers/gallifrey-types/].
+This proposal is based on work from the PLDI 2022 paper [A Flexible Type System for Fearless Concurrency](https://www.cs.cornell.edu/andru/papers/gallifrey-types/).
 
 Thanks to Doug Gregor, Kavon Farvardin for early assistance to Joshua during his
 internship.

proposals/0424-custom-isolation-checking-for-serialexecutor.md

@@ -22,7 +22,7 @@ The following example demonstrates such a situation:
 import Dispatch
 
 actor Caplin {
-  let queue: DispatchSerialQueue(label: "CoolQueue")
+  let queue: DispatchSerialQueue = .init(label: "CoolQueue")
 
   var num: Int // actor isolated state
 
@@ -35,9 +35,9 @@ actor Caplin {
     queue.async {
       // guaranteed to execute on `queue`
       // which is the same as self's serial executor
-      queue.assertIsolated() // CRASH: Incorrect actor executor assumption
-      self.assumeIsolated {  // CRASH: Incorrect actor executor assumption
-        num += 1
+      self.queue.assertIsolated() // CRASH: Incorrect actor executor assumption
+      self.assumeIsolated { caplin in // CRASH: Incorrect actor executor assumption
+        caplin.num += 1
       }
     }
   }
@@ -132,7 +132,7 @@ Specific use-cases of this API include `DispatchSerialQueue`, which would be abl
 // Dispatch 
 
 extension DispatchSerialQueue { 
-  public func checkIsolated(message: String) {
+  public func checkIsolated() {
     dispatchPrecondition(condition: .onQueue(self)) // existing Dispatch API
   }
 }
@@ -191,7 +191,7 @@ The custom heurystics that are today part of the Swift Concurrency runtime to de
 ```swift
 // concurrency runtime pseudo-code
 if expectedExecutor.isMainActor() {
-  expectedExecutor.checkIsolated(message: message)
+  expectedExecutor.checkIsolated()
 }
 ```
 

proposals/0430-transferring-parameters-and-results.md

@@ -3,9 +3,11 @@
 * Proposal: [SE-0430](0430-transferring-parameters-and-results.md)
 * Authors: [Michael Gottesman](https://github.com/gottesmm), [Holly Borla](https://github.com/hborla), [John McCall](https://github.com/rjmccall)
 * Review Manager: [Becca Royal-Gordon](https://github.com/beccadax)
-* Status: **Implemented (Swift 6.0)** 
+* Status: **Active Review (June 21 ... 28, 2024)** 
+* Implementation: Implemented in Swift 6.0 except for amendment under review
 * Previous Proposal: [SE-0414: Region-based isolation](/proposals/0414-region-based-isolation.md)
-* Review: ([pitch](https://forums.swift.org/t/pitch-transferring-isolation-regions-of-parameter-and-result-values/70240)) ([first review](https://forums.swift.org/t/se-0430-transferring-isolation-regions-of-parameter-and-result-values/70830)) ([returned for revision](https://forums.swift.org/t/returned-for-revision-se-0430-transferring-isolation-regions-of-parameter-and-result-values/71297)) ([second review](https://forums.swift.org/t/se-0430-second-review-sendable-parameter-and-result-values/71685)) ([acceptance with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0430-second-review-sendable-parameter-and-result-values/71850))
+* Previous Revisions: [1](https://github.com/apple/swift-evolution/blob/87943205551af43682ef50260816f3ff2ef9b7ea/proposals/0430-transferring-parameters-and-results.md) [2](https://github.com/apple/swift-evolution/blob/4dded8ed382b526a5a301c225a1d45018f8d556b/proposals/0430-transferring-parameters-and-results.md)
+* Review: ([pitch](https://forums.swift.org/t/pitch-transferring-isolation-regions-of-parameter-and-result-values/70240)) ([first review](https://forums.swift.org/t/se-0430-transferring-isolation-regions-of-parameter-and-result-values/70830)) ([returned for revision](https://forums.swift.org/t/returned-for-revision-se-0430-transferring-isolation-regions-of-parameter-and-result-values/71297)) ([second review](https://forums.swift.org/t/se-0430-second-review-sendable-parameter-and-result-values/71685)) ([acceptance with modifications](https://forums.swift.org/t/accepted-with-modifications-se-0430-second-review-sendable-parameter-and-result-values/71850)) ([amendment pitch](https://forums.swift.org/t/pitch-revise-se-0430-to-adopt-sending-on-unsafecontinuation/72289)) ([amendment review](https://forums.swift.org/t/amendment-se-0430-sending-parameter-and-result-values/72653))
 
 
 ## Introduction
@@ -370,12 +372,12 @@ struct Y2: P1 {
 }
 ```
 
-### `sending inout` parameters
+### `inout sending` parameters
 
 A `sending` parameter can also be marked as `inout`, meaning that the argument
 value must be in a disconnected region when passed to the function, and the
 parameter value must be in a disconnected region when the function
-returns. Inside the function, the `sending inout` parameter can be merged with
+returns. Inside the function, the `inout sending` parameter can be merged with
 actor-isolated callees or further sent as long as the parameter is
 re-assigned a value in a disconnected region upon function exit.
 
@@ -404,17 +406,15 @@ so there is no way to change the default ownership convention of a
 ### Adoption in the Concurrency library
 
 There are several APIs in the concurrency library that send a parameter across
-isolation boundaries and don't need the full guarnatees of `Sendable`.  These
+isolation boundaries and don't need the full guarantees of `Sendable`.  These
 APIs will instead adopt `sending` parameters:
 
 * `CheckedContinuation.resume(returning:)`
+* `UnsafeContinuation.resume(returning:)`
 * `Async{Throwing}Stream.Continuation.yield(_:)`
 * `Async{Throwing}Stream.Continuation.yield(with:)`
 * The `Task` creation APIs
 
-Note that this list does not include `UnsafeContinuation.resume(returning:)`,
-because `UnsafeContinuation` deliberately opts out of correctness checking.
-
 ## Source compatibility
 
 In the Swift 5 language mode, `sending` diagnostics are suppressed under
@@ -481,3 +481,66 @@ It was also suggested that perhaps instead of renaming `transferring` to
 authors since it runs into the same problem as `transferring` namely that it is
 suggesting that the value is actively being moved to another isolation domain,
 when we are expressing a latent capability of the value.
+
+### Exclude `UnsafeContinuation`
+
+An earlier version of this proposal excluded
+`UnsafeContinuation.resume(returning:)` from the list of standard library
+APIs that adopt `sending`.  This meant that `UnsafeContinuation` didn't
+require either the return type to be `Sendable` or the return value to be
+`sending`.  Since `UnsafeContinuation` is unconditionally `Sendable`, this
+effectively made it a major hole in sendability checking.
+
+This was an intentional choice.  The reasoning was that `UnsafeContinuation`
+was already an explicitly unsafe type, and so it's not illogical for it
+to also work as an unsafe opt-out from sendability checks.  There are some
+uses of continuations that do need an opt-out like this.  For example, it
+is not uncommon for a continuation to be resumed from a context that's
+isolated to the same actor as the context that called `withUnsafeContinuation`.
+In this situation, the data flow through the continuation is essentially
+internal to the actor.  This means there's no need for any sendability
+restrictions; both `sending` and `Sendable` would be over-conservative.
+
+However, the nature of the unsafety introduced by this exclusion is very
+different from the normal unsafety of an `UnsafeContinuation`.
+Continuations must be resumed exactly once; that's the condition that
+`CheckedContinuation` checks.  If a programmer can prove that
+they will do that to their own satisfaction, they should be able to use
+`UnsafeContinuation` instead of `CheckedContinuation` in full confidence.
+Making `UnsafeContinuation` *also* a potential source of concurrency-safety
+holes is likely to be surprising to programmers.
+
+Conversely, if a programmer needs to opt out of sendability checks but
+is *not* confident about how many times their continuation will be
+resumed --- for example, if it's resumed from an arbitrary callback ---
+forcing them to adopt `UnsafeContinuation` in order to achieve their
+goal is actively undesirable.
+
+Not requiring `sending` in `UnsafeContinuation` also makes the high-level
+interfaces of `UnsafeContinuation` and `CheckedContinuation` inconsistent.
+This means that programmers cannot always easily move from an unsafe to a
+checked continuation.  That is a common need, for example when fixing
+a bug and trying to prove that the unsafe continuation is not implicated.
+
+Swift has generally resisted adding new dimensions of unsafety to unsafe
+types this way.  For example, `UnsafePointer` was originally specified as
+unconditionally `Sendable` in [SE-0302][], but that conformance was
+removed in [SE-0331][], and pointers are now unconditionally
+non-`Sendable`.  The logic in both of those proposals closely parallels
+this one: at first, `UnsafePointer` was seen as an unsafe type that should
+not be burdened with partial safety checks, and then the community
+recognized that this was actually adding a new dimension of unsafety to
+how the type interacted with concurrency.
+
+Finally, there is already a general unsafe opt-out from sendability
+checking: `nonisolated(unsafe)`.  It is better for Swift to encourage
+consistent use of a single unsafe opt-out than to build *ad hoc*
+opt-outs into many different APIs, because it is much easier to find,
+recognize, and audit uses of the former.
+
+For these reasons, `UnsafeContinuation.resume(returning:)` now requires
+its argument to be `sending`, and the result of `withUnsafeContinuation`
+is correspondingly now marked as `sending`.
+
+[SE-0302]: https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md
+[SE-0331]: https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md

proposals/0434-global-actor-isolated-types-usability.md

@@ -5,7 +5,7 @@
 * Review Manager: [John McCall](https://github.com/rjmccall)
 * Status: **Implemented (Swift 6.0)**
 * Upcoming Feature Flag: `GlobalActorIsolatedTypesUsability`
-* Review: ([pitch](https://forums.swift.org/t/pitch-usability-of-global-actor-isolated-types/70799)) ([review](https://forums.swift.org/t/se-0434-usability-of-global-actor-isolated-types/71187))
+* Review: ([pitch](https://forums.swift.org/t/pitch-usability-of-global-actor-isolated-types/70799)) ([review](https://forums.swift.org/t/se-0434-usability-of-global-actor-isolated-types/71187)) ([acceptance](https://forums.swift.org/t/accepted-se-0434-usability-of-global-actor-isolated-types/72743))
 
 ## Introduction
 
@@ -248,6 +248,10 @@ An alternative choice would be to introduce an upcoming feature flag that's enab
 
 The existing adoption implications of `@Sendable` and global actor isolation adoption apply when making use of the rules in this proposal. For example, `@Sendable` and `@MainActor` can be staged into existing APIs using `@preconcurrency`. See [SE-0337: Incremental migration to concurrency checking](/proposals/0337-support-incremental-migration-to-concurrency-checking.md) for more information.
 
+## Alternatives considered
+
+Instead of implicitly suppressing a `Sendable` conformance on isolated subclasses of non-`Sendable`, non-isolated superclasses, the compiler could instead require an explicit opt-out, such as `~Sendable` in the conformance clause. This would make it obvious that the subclass does not have a `Sendable` conformance. However, the programmer does not need to understand that the class does not conform to `Sendable` until they use the type in a way that requires `Sendable`, and the reason for the class not conforming to `Sendable` can be explained with notes attached to the diagnostic. It is also not always the case that global actor isolation implies `Sendable`. Notably, `@MainActor` on a protocol does not imply that the protocol refines `Sendable`, so requiring more boilerplate for programmers in the isolated subclass case does not leave the programmer with a simple rule to remember about when `@MainActor` implies a conformance to `Sendable`.
+
 ## Acknowledgments
 
 Thank you to Frederick Kellison-Linn for surfacing the problem with global-actor-isolated function types, and to Kabir Oberai for exploring the implications more deeply.