Pitch #2: Protocol-based Actor Isolation

Evolution Pitches
27

Sorry for the long delay here... this proposal is definitely moving in the right direction. Here are a couple of comments:

  • Something like @UnsafeTransfer feels like it needs to be part of the core proposal, because the lack of an opt-out here either hampers adoption or pushes people to incorrectly introduce conformances to ActorSendable. However, the property wrapper implementation isn't actually that great, because it has ABI impact. I suggest that @unsafeTransfer be a real attribute and a core part of the proposal.

  • From a performance perspective, we should consider formalizing the notion of a "marker" protocol for ActorSendable / ValueSemantics, banning any of the dynamic features that would force us to emit a witness table in the metadata. For example, we could ban the use of such protocols in existential types and dynamic casts (no var a: ActorSendable or x as? ActorSendable in the source language) so that there is no ABI impact to the introduction and use of such protocols. This also means we don't have to worry about multiple conformances quite so much, which might help with rollout as (e.g.) lots of people add ActorSendable conformances to third-party types that will cause conflicts.

  • I don't think this proposal should be tied to value semantics at all. Yes, value semantics provide actor-sendability, but there's a natural layering here and you don't need to block progress on this proposal on value semantics. (Yes, I'm worried that discussion won't converge, given that it's been simmering for years)

  • I think the name ActorSendable isn't quite right, because (1) this could/should be more general than actors, if we go and apply this to captured local variables, and (2) it's not just about "sending" values, both due to captured local variables and also because we're currently allowing let values to be accessed from other contexts. How about Shareable, because it's safe to share values of the type across tasks/threads/actors? That could be paired with @unsafeShareable to disable the checking on a per-parameter basis.

    Doug

8 Likes