Merge pull request #2460 from stzn/patch-3

[SE-0430] Change `sendable` to `sending`

Author: gottesmm

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

@@ -1,4 +1,4 @@
-# `sendable` parameter and result values
+# `sending` parameter and result values
 
 * 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)
@@ -12,8 +12,8 @@
 ## Introduction
 
 This proposal extends region isolation to enable the application of an explicit
-`sendable` annotation to function parameters and results. A function parameter
-or result that is annotated with `sendable` is required to be disconnected at
+`sending` annotation to function parameters and results. A function parameter
+or result that is annotated with `sending` is required to be disconnected at
 the function boundary and thus possesses the capability of being safely sent
 across an isolation domain or merged into an actor-isolated region in the
 function's body or the function's caller respectively.
@@ -140,17 +140,17 @@ used again after the call to `resume(returning:)`.
 
 This proposal enables explicitly specifying parameter and result values as
 possessing the capability of being sent over an isolation boundary by annotating
-the value with a contextual `sendable` keyword:
+the value with a contextual `sending` keyword:
 
 ```swift
 public struct CheckedContinuation<T, E: Error>: Sendable {
-  public func resume(returning value: sendable T)
+  public func resume(returning value: sending T)
 }
 
 public func withCheckedContinuation<T>(
     function: String = #function,
     _ body: (CheckedContinuation<T, Never>) -> Void
-) async -> sendable T
+) async -> sending T
 ```
 
 ## Detailed design
@@ -166,35 +166,35 @@ the value's entire region implying that all uses of the value (and anything
 non-`Sendable` typed that can be reached from the value) must end in the source
 concurrency context before any uses can begin in the destination concurrency
 context. Swift achieves this property by requiring that the value is in a
-disconnected region and we say that such a value is a `sendable` value.
+disconnected region and we say that such a value is a `sending` value.
 
 Thus a newly-created value with no connections to existing regions is always a
-`sendable` value:
+`sending` value:
 
 ```swift
 func f() async {
-  // This is a `sendable` value since we can transfer it safely...
+  // This is a `sending` value since we can transfer it safely...
   let ns = NonSendable()
 
   // ... here by calling 'sendToMain'.
   await sendToMain(ns)
 }
 ```
 
-Once defined, a `sendable` value can be merged into other isolation
+Once defined, a `sending` value can be merged into other isolation
 regions. Once merged, such regions, if not disconnected, will prevent the value
 from being sent to another isolation domain implying that the value is no longer
-a `sendable` value:
+a `sending` value:
 
 ```swift
 actor MyActor {
   var myNS: NonSendable
 
   func g() async {
-    // 'ns' is initially a `sendable` value since it is in a disconnected region...
+    // 'ns' is initially a `sending` value since it is in a disconnected region...
     let ns = NonSendable()
 
-    // ... but once we assign 'ns' into 'myNS', 'ns' is no longer a sendable
+    // ... but once we assign 'ns' into 'myNS', 'ns' is no longer a sending
     // value...
     myNS = ns
 
@@ -204,43 +204,43 @@ actor MyActor {
 }
 ```
 
-If a `sendable` value's isolation region is merged into another disconnected
-isolation region, then the value is still considered to be `sendable` since two
+If a `sending` value's isolation region is merged into another disconnected
+isolation region, then the value is still considered to be `sending` since two
 disconnected regions when merged form a new disconnected region:
 
 ```swift
 func h() async {
-  // This is a `sendable` value.
-  let ns = NonSendable()
+  // This is a `sending` value.
+  let ns = Nonsending()
 
-  // This also a `sendable value.
+  // This also a `sending value.
   let ns2 = NonSendable()
 
   // Since both ns and ns2 are disconnected, the region associated with
-  // tuple is also disconnected and thus 't' is a `sendable` value...
+  // tuple is also disconnected and thus 't' is a `sending` value...
   let t = (ns, ns2)
 
   // ... that can be sent across a concurrency boundary safely.
   await sendToMain(ns)
 }
 ```
 
-### Sendable Parameters and Results
+### sending Parameters and Results
 
-A `sendable` function parameter requires that the argument value be in a
+A `sending` function parameter requires that the argument value be in a
 disconnected region. At the point of the call, the disconnected region is no
 longer in the caller's isolation domain, allowing the callee to send the
 parameter value to a region that is opaque to the caller:
 
 ```swift
 @MainActor
-func acceptSend(_: sendable NonSendable) {}
+func acceptSend(_: sending NonSendable) {}
 
 func sendToMain() async {
   let ns = NonSendable()
 
   // error: sending 'ns' may cause a race
-  // note: 'ns' is passed as a 'sendable' parameter to 'acceptSend'. Local uses could race with
+  // note: 'ns' is passed as a 'sending' parameter to 'acceptSend'. Local uses could race with
   //       later uses in 'acceptSend'.
   await acceptSend(ns)
 
@@ -253,28 +253,28 @@ What the callee does with the argument value is opaque to the caller; the callee
 may send the value away, or it may merge the value to the isolation region of
 one of the other parameters.
 
-A `sendable` result requires that the function implementation returns a value in
+A `sending` result requires that the function implementation returns a value in
 a disconnected region:
 
 ```swift
 @MainActor
 struct S {
   let ns: NonSendable
 
-  func getNonSendableInvalid() -> sendable NonSendable {
+  func getNonSendableInvalid() -> sending NonSendable {
     // error: sending 'self.ns' may cause a data race
-    // note: main actor-isolated 'self.ns' is returned as a 'sendable' result.
+    // note: main actor-isolated 'self.ns' is returned as a 'sending' result.
     //       Caller uses could race against main actor-isolated uses.
     return ns
   }
 
-  func getNonSendable() -> sendable NonSendable {
+  func getNonSendable() -> sending NonSendable {
     return NonSendable() // okay
   }
 }
 ```
 
-The caller of a function returning a `sendable` result can assume the value is
+The caller of a function returning a `sending` result can assume the value is
 in a disconnected region, enabling non-`Sendable` typed result values to cross
 an actor isolation boundary:
 
@@ -290,75 +290,75 @@ nonisolated func f(s: S) async {
 
 ### Function subtyping
 
-For a given type `T`, `sendable T` is a subtype of `T`. `sendable` is
+For a given type `T`, `sending T` is a subtype of `T`. `sending` is
 contravariant in parameter position; if a function type is expecting a regular
-parameter of type `T`, it's perfectly valid to pass a `sendable T` value
+parameter of type `T`, it's perfectly valid to pass a `sending T` value
 that is known to be in a disconnected region. If a function is expecting a
-parameter of type `sendable T`, it is not valid to pass a value that is not
+parameter of type `sending T`, it is not valid to pass a value that is not
 in a disconnected region:
 
 ```swift
-func sendableParameterConversions(
-  f1: (sendable NonSendable) -> Void,
+func sendingParameterConversions(
+  f1: (sending NonSendable) -> Void,
   f2: (NonSendable) -> Void
 ) {
-  let _: (sendable NonSendable) -> Void = f1 // okay
-  let _: (sendable NonSendable) -> Void = f2 // okay
+  let _: (sending NonSendable) -> Void = f1 // okay
+  let _: (sending NonSendable) -> Void = f2 // okay
   let _: (NonSendable) -> Void = f1 // error
 }
 ```
 
-`sendable` is covariant in result position. If a function returns a value
-of type `sendable T`, it's valid to instead treat the result as if it were
+`sending` is covariant in result position. If a function returns a value
+of type `sending T`, it's valid to instead treat the result as if it were
 merged with the other parameters. If a function returns a regular value of type
 `T`, it is not valid to assume the value is in a disconnected region:
 
 ```swift
-func sendableResultConversions(
-  f1: () -> sendable NonSendable,
+func sendingResultConversions(
+  f1: () -> sending NonSendable,
   f2: () -> NonSendable
 ) {
-  let _: () -> sendable NonSendable = f1 // okay
-  let _: () -> sendable NonSendable = f2 // error
+  let _: () -> sending NonSendable = f1 // okay
+  let _: () -> sending NonSendable = f2 // error
   let _: () -> NonSendable = f1 // okay
 }
 ```
 
 ### Protocol conformances
 
-A protocol requirement may include `sendable` parameter or result annotations:
+A protocol requirement may include `sending` parameter or result annotations:
 
 ```swift
 protocol P1 {
-  func requirement(_: sendable NonSendable)
+  func requirement(_: sending NonSendable)
 }
 
 protocol P2 {
-  func requirement() -> sendable NonSendable
+  func requirement() -> sending NonSendable
 }
 ```
 
 Following the function subtyping rules in the previous section, a protocol
-requirement with a `sendable` parameter may be witnessed by a function with a
+requirement with a `sending` parameter may be witnessed by a function with a
 non-`Sendable` typed parameter:
 
 ```swift
 struct X1: P1 {
-  func requirement(_: sendable NonSendable) {}
+  func requirement(_: sending NonSendable) {}
 }
 
 struct X2: P1 {
   func requirement(_: NonSendable) {}
 }
 ```
 
-A protocol requirement with a `sendable` result must be witnessed by a function
-with a `sendable` result, and a requirement with a plain result of type `T` may
-be witnessed by a function returning a `sendable T`:
+A protocol requirement with a `sending` result must be witnessed by a function
+with a `sending` result, and a requirement with a plain result of type `T` may
+be witnessed by a function returning a `sending T`:
 
 ```swift
 struct Y1: P1 {
-  func requirement() -> sendable NonSendable {
+  func requirement() -> sending NonSendable {
     return NonSendable()
   }
 }
@@ -371,42 +371,42 @@ struct Y2: P1 {
 }
 ```
 
-### `sendable inout` parameters
+### `sending inout` parameters
 
-A `sendable` parameter can also be marked as `inout`, meaning that the argument
+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 `sendable inout` parameter can be merged with
+returns. Inside the function, the `sending inout` 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.
 
-### Ownership convention for `sendable` parameters
+### Ownership convention for `sending` parameters
 
-When a call passes an argument to a `sendable` parameter, the caller cannot
-use the argument value again after the callee returns. By default `sendable`
+When a call passes an argument to a `sending` parameter, the caller cannot
+use the argument value again after the callee returns. By default `sending`
 on a function parameter implies that the callee consumes the parameter. Like
-`consuming` parameters, a `sendable` parameter can be re-assigned inside
-the callee. Unlike `consuming` parameters, `sendable` parameters do not
+`consuming` parameters, a `sending` parameter can be re-assigned inside
+the callee. Unlike `consuming` parameters, `sending` parameters do not
 have no-implicit-copying semantics.
 
 To opt into no-implicit-copying semantics or to change the default ownership
-convention, `sendable` may also be paired with an explicit `consuming` or
+convention, `sending` may also be paired with an explicit `consuming` or
 `borrowing` ownership modifier:
 
 ```swift
-func sendableConsuming(_ x: consuming sendable T) { ... }
-func sendableBorrowing(_ x: borrowing sendable T) { ... }
+func sendingConsuming(_ x: consuming sending T) { ... }
+func sendingBorrowing(_ x: borrowing sending T) { ... }
 ```
 
 Note that an explicit `borrowing` annotation always implies no-implicit-copying,
 so there is no way to change the default ownership convention of a
-`sendable` parameter without also opting into no-implicit-copying semantics.
+`sending` parameter without also opting into no-implicit-copying semantics.
 
 ### 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
-APIs will instead adopt `sendable` parameters:
+APIs will instead adopt `sending` parameters:
 
 * `CheckedContinuation.resume(returning:)`
 * `Async{Throwing}Stream.Continuation.yield(_:)`
@@ -418,11 +418,11 @@ because `UnsafeContinuation` deliberately opts out of correctness checking.
 
 ## Source compatibility
 
-In the Swift 5 language mode, `sendable` diagnostics are suppressed under
+In the Swift 5 language mode, `sending` diagnostics are suppressed under
 minimal concurrency checking, and diagnosed as warnings under strict concurrency
 checking. The diagnostics are errors in the Swift 6 language mode, as shown in
 the code examples in this proposal. This diagnostic behavior based on language
-mode allows `sendable` to be adopted in existing Concurrency APIs including
+mode allows `sending` to be adopted in existing Concurrency APIs including
 `CheckedContinuation`.
 
 ## ABI compatibility
@@ -431,21 +431,21 @@ This proposal does not change how any existing code is compiled.
 
 ## Implications on adoption
 
-Adding `sendable` to a parameter is more restrictive at the caller, and
-more expressive in the callee. Adding `sendable` to a result type is more
+Adding `sending` to a parameter is more restrictive at the caller, and
+more expressive in the callee. Adding `sending` to a result type is more
 restrictive in the callee, and more expressive in the caller.
 
-For libraries with library evolution, `sendable` changes name mangling, so
+For libraries with library evolution, `sending` changes name mangling, so
 any adoption must preserve the mangling using `@_silgen_name`. Adoping
-`sendable` must preserve the ownership convention of parameters; no
+`sending` must preserve the ownership convention of parameters; no
 additional annotation is necessary if the parameter is already (implicitly or
 explicitly) `consuming`.
 
 ## Future directions
 
 ### `Disconnected` types
 
-`sendable` requires parameter and result values to be in a disconnected
+`sending` requires parameter and result values to be in a disconnected
 region at the function boundary, but there is no way to preserve that a value
 is in a disconnected region through stored properties, collections, function
 calls, etc. To preserve that a value is in a disconnected region through the
@@ -455,11 +455,11 @@ would conform to `Sendable`, constructing a `Disconnected` instance would
 require the value it wraps to be in a disconnected region, and a value of type
 `Disconnected` can never be merged into another isolation region.
 
-This would enable important patterns that take a `sendable T` parameter, store
+This would enable important patterns that take a `sending T` parameter, store
 the value in a collection of `Disconnected<T>`, and later remove values from the
-collection and return them as `sendable T` results. This would allow some
+collection and return them as `sending T` results. This would allow some
 `AsyncSequence` types to return non-`Sendable` typed buffered elements as
-`sendable` without resorting to unsafe opt-outs in the implementation.
+`sending` without resorting to unsafe opt-outs in the implementation.
 
 ## Alternatives considered