SE-0430 (second review): `sendable` parameter and result values

[Michael_Gottesman]

@grynspan

Keeping my novice hat on for a bit longer… I see this discussion of sendable vs. consuming:

When a call passes an argument to a sendable parameter, the caller cannot use the argument value again after the callee returns. [...] Unlike consuming parameters, sendable parameters do not have no-implicit-copying semantics.

And I wonder whether the distinction between sendable and consuming is semantically important at the source level? I (hat off for a second here) understand it affects codegen, at least as implemented today, but from an external developer's perspective, would it make sense to just use consuming here?

With consuming one gets a var like argument + no implicit copy diagnostics, while with sendable one just gets a var like argument. From a codegen perspective they are actually the same. The only difference is the additional diagnostic.

The reason why it is separated is that conceptually one may not want sendable to imply no implicit copy. One can always achieve that by marking the parameter consuming sendable.

I'm unsure under what conditions I would want borrowing sendable. An example would be helpful.

borrowing sendable is mainly expected to be used in situations where one needs to change an API to use sendable, but one cannot change from +0 -> +1 due to ABI constraints. An example of this would be the Continuation.yield(with:) API in AsyncStream. The API takes a result at +0 so if we changed the parameter to be just sendable, we would be breaking ABI.

sendable inout (but not inout sendable?) could also use some more explanation. I would assume that it means the value is transferred into the callee's domain for computation, then transferred back, but how would that differ from the normal semantics of inout? Could sendable simply be inferred here, or are there dangers in doing so?

It will actually be inout sendable. That is just a typo in the proposal.

The difference is that an inout parameter only provides guarantees around the actual memory usage of the var. It doesn't provide any guarantees around concurrency. Consider the following:

class MyKlass {
}

@MainActor func sendToMain<T>(_ t: T) async { ... }

func f(_ x: inout MyKlass) async {
  await sendToMain(x)
}

func g() {
  var x = MyKlass()
  f(&x)
  print(x)
}

There is nothing in the current semantics of inout that would prevent this code from being written and we would have a race in between print(x) and whatever occurs in sendToMain(x).

The interesting use case here can be seen in the mutex proposal where it is used: [Pitch] Synchronous Mutual Exclusion Lock.