Re: PHP True Async RFC Stage 4

On Thu, Oct 16, 2025, at 09:08, Edmond Dantes wrote: > > I would expect more than "because I said so" > > In my response I provided arguments, but they were ignored. If you > tell me exactly what is unclear to you, I can give a concrete, > well-reasoned answer. > This is all I have to go off of, and my explicit rebuttals as to why they are not reasons: > Therefore, if a Scope needs to be awaited, it can only be done > together with a cancellation token. This is effectively not true. I can pass a cancellation token that never cancels. Sometimes, this is exactly the behaviour that is desired. > In real-world scenarios, awaiting a Scope during normal > execution > makes no sense, because you have a cancellation policy. > This means that at any necessary moment you can dispose() the > Scope > and thus interrupt the execution of tasks inside the black box. That sounds like a feature, not a reason. > For the TaskGroup pattern, which exists in the third version of > the > RFC, awaiting is a relatively safe operation, because in this case we > assume that the code is written by someone who has direct access to > the agreements and bears full responsibility for any errors. We aren't talking about TaskGroups, but regardless, I fail to understand how that makes scopes 'dangerous' to await and why it should not be Awaitable. > So, Scope is intended for components where responsibility is > shared > between different programmers, while TaskGroup should be used > when > working with a clearly defined set of coroutines. My question is "why does this mean something with an await method isn't Awaitable?" -- it seems that this is orthogonal to the interface and the reason why it should/should not be Awaitable. — Rob