> In a syntax-and-semantics approach, we only need to describe the things people actually need.
There is no doubt that syntax provides the programmer with a clear tool for expressing intent. > In the same way, do we actually need to design what an "async context" looks like to the user? Its implementation is more about deciding which paradigms we want to support. If we want to support global services that require local state within a coroutine, then they need a context. If there are no global "impure" services (i.e., those maintaining state within a coroutine), then a context may not be necessary. The first paradigm is not applicable to pure multitasking—almost all programming languages (as far as I know) have abandoned it in favor of ownership/memory passing. However, in PHP, it is popular. For example, PHP has functions for working with HTTP. One of them writes the last received headers into a "global" variable, and another function allows retrieving them. This is where a context is needed. Or, for instance, when a request is made inside a coroutine, the service that handles socket interactions under the hood must: 1. Retrieve a socket from the connection pool. 2. Place the socket in the coroutine’s context for as long as it is needed. However, this same scenario could be implemented more elegantly if PHP code explicitly used an object like "Connection" or "Transaction" and retrieved it from the pool. In that case, a context would not be needed. Thus, the only question is: do we need to maintain state between function/method calls within a coroutine? > Do we actually want the user to be able to have access to two (nested) async contexts at once, and choose which one to spawn a task into? If we discard the Go model, where the programmer decides what to do and which foot to shoot themselves in, and instead use parent-child coroutines, then such a function breaks this rule. This means it should not exist, as its presence increases system complexity. However, in the parent-child model, there is a case where a coroutine needs to be created in a different context. For example: - A request to reset a password arrives at the server. - The API creates a coroutine in a separate context from the request to send an email. - The API returns a 201 response. In this case, a special API is needed to accomplish this. The downside of any strict semantics is the presence of exceptional cases. However, such cases should be rare. If they are not, then the parent-child model is not suitable. To resolve this issue, we need to know the opinions of framework maintainers. They should say either: *Yes, this approach will reduce the amount of code*, or *No, it will increase the codebase*, or *We don't care, do as you like* :)
