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
