Hello, Rowan! > I don't have time to dig into the details of this draft at the moment, but will say that a vote in two weeks is not at all realistic. I just used the Flow from the Wiki. :)
> My only other comment at a very quick glance is that I see the Context section is still included, and still has most of its complexity. Almost every section of the RFC has a "Motivation" subsection, which explains why a particular tool is needed and what problem it solves. I removed everything from the RFC that is not directly related to asynchrony or not essential at this stage. Yesterday I also received feedback that the RFC contains too many changes, so I can briefly summarize what’s new in this version compared to the previous one: 1. The Scope class can no longer be used in an await expression. A separate method is now provided for waiting on a Scope, intended only for special use cases. 2. Scope is now responsible solely for coroutine lifetime and error handling. 3. A TaskGroup class has been added for working with groups of tasks. It is used explicitly with the expression spawn with $taskGroup. Together with Scope, TaskGroup supports structured concurrency, offering different strategies for tracking hanging coroutines. *These are the key changes.* *Secondary changes include:* 1. Syntax refinement 2. Edge case handling 3. Ability to extend spawn with logic 4. Added combinator functions: all, any, anyOf, ignoreErrors 5. A special function Async\protect() has been added for critical sections that cannot be cancelled. 6. Improved examples Contextual expressions like with $context and async blocks were removed from the RFC as they are out of its scope. The next important step is to determine which coroutine model to choose. There are three models in total: 1. Go – no Scope 2. Java Loom – Scope is always passed explicitly 3. The current RFC – Scope is passed both explicitly and implicitly The choice of model affects both the syntax and the API. Therefore, if the current model is not accepted, there is no point in further developing this RFC — a new one should be created instead. This is the key question I want to clarify at this stage. -- Ed
