Since old concurrency manifesto and through implementation story there was a notion of sending messages to actors in a unidirectional way. However, when actors has landed, the choice — reasonably – was made towards more practical and more widely applicable solution with await's, which is great. Yet so far I've been wanting to have an ability to have this unidirectional messages – and seems to be not only one, as they can be useful and help to avoid introducing more asynchronous functions where this might be unwanted and offer a great tool expanding actors model even further in the language. Are there any plans to get this during minor Swift 6.x releases?
While we may need still revisit a send-like operation sometime for other reasons, the semantic equivalent of it is achieved once this proposal is implemented: Closure isolation control
and It'd be spelled as Task { await target.hello() }.
That proposal changes the enqueue semantics to become "immediately enqueue on target" (since we notice that's the first thing this does), as well as the explicit version of it Task { [isolated target] in target.hello() } which the proposal discusses (and also would mean "enqueue immediately".
There's some more tricky things here with distributed actors, as you may need to express that an "uni-directional" -> Void is significantly different than a -> Void that you must wait for etc.
So there's more to be discussed, but currently the thinking is towards those closure isolation control and changing the enqueue behavior. It handles most of the cases.
6 Likes
Oh, I’ve almost forgot about this one. Thanks for the answer! Are there any updates on the proposal? Or is it just being waiting for Swift 6 to release (as I assume there are a lot of work to be done apart from that)?
I’d still be in favor of send target.hello() or similar syntax to get as subsequent change after closure isolation control, since it would be much easier to reason about: creating unstructured task IMO communicates that in much less obvious way, requiring to keep the call semantics in the head as well as explaining this bits.
Updates about the proposal will be in that thread 
There's not been any new action on it recently though. We plan to get back to it soon though.
send would still be call-site, which I wonder if it's still interesting if we can express the same using the adjusted Task initializer ordering/enqueue semantics... We'll have to deep dive what use-cases are served and what still needs semantic adjustments, the sugar can follow after that.
1 Like
I agree that getting it work in that way is much more important than syntactic sugar around. Thanks!