Pitch #2: Protocol-based Actor Isolation

[Douglas_Gregor]

@Chris_Lattner3

I don't understand how you are imagining that this works: there are no actors, so there is no isolation, and therefore no memory safety. I haven't fully paged in the structured concurrency and nursery stuff, but async let must imply deep magic if this is creating concurrent tasks without an actor boundary between them. I'm a bit concerned about this as a prospect, but again, I haven't followed that line of development (I was waiting for rev #2 of the proposal).

If this ends up being a thing and if this proposal is useful to help with it, then I agree with you that we should pick a different word than Actor on ActorTransferrable , maybe ConcurrencyDomainTransferrable or something like that. I don't think that making the name fully generic like "sendable" (or some other verb) will work out well.

I took a stab at this over in a new thread on preventing data races. It categorizes the various places where we have mutable state that can have data races (local variables, global/static variables, class instance variables) and how to deal with them. It also goes into how we can phase in the checking of these properties.

I was originally envisioning this as part of the Structured Concurrency proposal for "revision 2", but it belongs as a separate document even if parts of it get folded back into the proposal later.

Doug