SE-0302: ConcurrentValue and @concurrent closures

[Douglas_Gregor]

@xwu

Seems fine to me if we go down the @unchecked Transferrable/Sendable route; I was more thinking that if there is a desire to stick to the current design of having two protocols, the unchecked one could play up the distinction of why it's unchecked or unsafe by going with a name such as Synchronized .

I can see the value of Synchronized as effectively documentation that a particular class is concurrency-safe because it provides implicit synchronization, which is distinct from being concurrency-safe because the class is immutable. However, Synchronized feels like something that could be checked, and I hesitate to introduce the name and implied semantics without also having some checking in place, because it would be harder to add the checking later.

@benrimmington

Could the same @sendable — or @sendable(unsafe) — attribute be used:

• on function types as proposed.
• on "unsafe" function parameters, instead of an @UnsafeTransfer wrapper?
• on "unsafe" stored properties, instead of an UnsafeSendable protocol?
• on "non-trivial" stored properties, in the standard library types?
• on "retroactive" Sendable conformances?

struct MyPerson: Sendable {
  var name: String
  var age: Int
}

struct MyNSPerson: Sendable {
  @sendable(unsafe) var name: NSMutableString
  @sendable(unsafe) var age: NSNumber
}

There is considerable overlap between this attribute and nonisolated(unsafe) in the actors pitch: both allow specific declarations to opt out of the checking that would normally be done to prevent data races. The primary use case for actors is to take a specific stored instance property and allow access to it from code not protected by the actor's mailbox, meaning you need to handle the synchronization yourself. It's very nearly what we're looking for here, but we would need a more general term to describe it. It's more than "sendable" and it's not specific to actors.

What if we call it @concurrent(unsafe)? It would mean "turn off safety checking related to concurrency", which means both allowing non-ConcurrentValue types (the @sendable(unsafe) behavior) as well as making a stored instance property in an actor not part of the actor's isolated state (subsuming nonisolated(unsafe)). We are already proposing @concurrent for function types, where @concurrent(unsafe) also makes sense: it should disable the checking that captures conform to ConcurrentValue.

Doug