> > The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async libraries, >
How exactly does it interfere with the implementation of asynchronous libraries? Especially considering that these libraries operate at the User-land level? It’s a contract. No more. No less. > > Libraries can full well handle cleanup of fibers in __destruct by themselves, without a wait_all block forcing them to reduce concurrency whenever the caller pleases. > Fiber is a final class, so there can be no destructors here. Even if you create a "Coroutine" class and allow defining a destructor, the result will be overly verbose code. I and many other developers have tested this. And the creators of AMPHP did not take this approach. Go doesn’t have it either. This is not a coincidence. > > It is, imo, a MAJOR FOOTGUN, and should not be even considered for implementation. > Why exactly is this a FOOTGUN? - Does this block lead to new violations of language integrity? - Does this block increase the likelihood of errors? A FOOTGUN is something that significantly breaks the language and pushes developers toward writing bad code. This is a rather serious flaw.
