>
> 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.