[Pitch #6] Actors

[Douglas_Gregor]

@BigSur

After re-reading the latest proposal, it'd be better to merge/simplify isolated/nonisolated notion. They are basically the same sync/@sync semantic from different(inside/outside) perspective/view for Actor .

• From outside of Actor, isolated Actor means switching to actor's executor to access stuff in sync way .
• From inside of Actor, nonisolated Actor.member means conform to non-isolated protocol requirements in traditional sync way or access stuff in-sync from anywhere.

So all in all, outside isolated Actor == inside nonisolated Actor.member == sync / @sync in semantic; there's no need to use two different antonym words to express the same thing.

They are just plain sync semantic meaning.

I made a similar argument in favor of @concurrent over @sendable over in the thread on SE-0302, and Joe Groff made an excellent point:

On the other hand, I think it'd be good fight back against the urge to wordsmith and keep the names aligned. Other unnecessarily different wordings in the language for the same concept, like mutating / inout and consuming / owned for self vs. other arguments, or class -in-protocols-and-classes-but- static -everywhere-else for type-level methods, create barriers for learning the language.

We're not just talking about isolated here. We're talking about isolated, and nonisolated, and all of the terminology around actors isolating their state. We should either revisit it all or leave this one be; it's better than introducing more inconsistency for the sake of a slightly-better meaning for one (relatively obscure) feature.

Doug