Awesome to have this reach review phase, congrats @Philippe_Hausler @Tony_Parker!
What is your evaluation of the proposal?
Strong +1, it is great to see the reactive programming / streams concepts woven into the async story of swift like this and have them feel natural and part of "what users would expect" rather than forcing them to re-learn a new style of programming
Very excited about the related proposal about rethrows protocols as well, that will make this proposal even nicer.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, it is an important piece of the puzzle; whereas without this we'd be limited to speak in terms of request/reply, now we're able to express
async APIs in terms of streaming or rather async sequences -- I should get used to the new word soon
Does this proposal fit well with the feel and direction of Swift?
Yes, it fitts well.
It is a missing piece to the concurrency story -- without it we'd be limited to only talk about unary asynchronous values, while with this proposal we're able to fit in asynchronous sequences/streams into Swift's normal control flow structures (
for), making it a natural fit for our async/await based direction
The semantics of this API fit well with the Structured Concurrency proposal, and also Actors (say, an actor returning a "streaming response"). Since async sequences use async functions, we will be able to use all related functionality with them -- including task-local values (notoriously difficult to get right in plain reactive programming libraries!), as well as cancelation etc.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I just realized that I never used a language in anger that had built-in language sugar for async sequences like this. Even though having worked on async sequence runtimes for years... funny heh, it always felt "so natural and obvious thing to do" though
I could compare it with how another language attempts to provide language sugar for FRP / reactive streams style APIs though: so I have contrasted it with how Kotlin attempts to bridge reactive-streams into the async/await. The style of syntax enabled by this proposal is more natural and fits Swift very well.
Other than API surface things which can be bikeshed forever, we notably differ in explicit task cancellation checking semantics. Kotlin takes the stance of automatically checking for cancelation of the task/coroutine within which it runs on every single emitted value edge, IMHO leading to too much noise/traffic on cancelation checking.
The here proposed semantics, that checking is up to the developer is more consistent with the language direction and co-operative cancellation semantics of Swift.
For context, I was one of the early co-authors of reactive-streams which eventually ended up as part of the Java standard library and also are adopted by Kotlin's Flow types. I also implemented large pieces of Akka Streams (similar to Combine) and have accumulated years of "if only we could have some sugar in the language" from building those library-only solutions – so, I'm very happy to see this take shape and it supports everything I would wish for
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Have been tracking its development, reviewing since early reviews as well as compared to semantics present in other runtimes which offer such sugar (Kotlin).
// edit: typos