Re: PHP True Async RFC Stage 4

On Thu, Oct 16, 2025, at 09:38, Daniil Gentili wrote: > > > You've provided examples and said that it violates design and fundamental elements, > > but not which design and fundamentals, ie, the evidence for the decision. I would expect more than > > "because I said so" for such a huge language feature, but rather arguments grounded in > > computer science. > > > He very explicitly described the issue, in objective terms: a breach of agreement in the > context of the invocation of a foreign interface. > > In simpler terms, you can't and should not be able to mess with the internals of code you > didn't write: this is similar to the principle of encapsulation in OOP, where you cannot modify > private properties of an object. > > > Cancellation should be part of the contract of an async function: it is safe, and most async > languages already implement it explicitly by passing a context or a cancellation token, the current > approach of the RFC does it implicitly, which is also fine. > > Awaiting for the completion of spawned coroutines should *not* be part of the contract of an > async function: it is an incredibly easy footgun, as it's incredibly easy to spawn a coroutine > meant to i.e. run until the object is destroyed, and then encounter a deadlock when the linked scope > is awaited for before the object is destroyed (even messier if cycles and thus the GC are involved). > > Languages like Kotlin that do implement await on scopes have already realized that it is a > mistake, as can be seen by the many warnings against using await on a scope, as I already linked in > previous emails. > > On the other hand, making the same mistake described above, by cancelling a scope, will produce > a very easy to debug exception instead of a deadlock, easily fixable by (warning the author of the > library class) to use a new scope to spawn coroutines within the object. > > Awaiting a scope leads to deadlocks in case where a separate scope is needed but not used, > cancelling them leads to a simple exception. > Awaiting on multiple tasks can already be done, explicitly, with TaskGroup. > > > Regards, > Daniil Gentili. Hey Daniil and Edmond, I think I understand the intention. Would it be better to instead of having ->awaitCompletion (which feels like an implicit implementation of Awaitable without an explicit implmentation -- which is the part that was bothering me), maybe having something like ->joinAll() or ->joinOnCancellation()? That way someone like me won't come along and wrap them in an Awaitable because it looks Awaitable. It also might be a good idea to make specifying a timeout in ms mandatory, instead of a taking an Awaitable/Cancellation. This would also prevent people from simply passing a "never returning" Awaitable thinking they're being clever. It also might be good to provide a realistic looking example showing a "bad case" of how this is dangerous instead of simply saying that it is, showing how a scope is not a 'future', but a container, and preemptively mention TaskGroups, linking to the future scope (which it should also probably be listed there as well). — Rob