> Offering this tool to userland is a major footgun that will either backfire spectacularly
> (breaking existing and new async libraries by endlessly awaiting upon background fibers when exiting
> an async {} block haphazardly used by a newbie, or even worse force library developers to reduce
> concurrency, killing async PHP just because users can use async {} blocks), or simply not get used
> at all (because the main SAPI usecase listed explicitly does NOT need purity).
Some extra points:
1) The naming of "async {}" is also very misleading, as it does the opposite of making
things async, if anything it should be called "wait_all {}"
2) Again, what are waiting for? A fiber spawned by a library we called 10 levels deep in the stack,
that exits only when the container object is destroyed (outside of the wait_all block, thus causing
an endless hang)? No one should care or be able to control what must remain an internal
implementation detail of invoked libraries, adding a wait_all block will only break stuff.
3) If we did want to wait for all fibers spawned by a method call, nothing is preventing the caller
from returning an array of futures for spawned fibers that we can await.
The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async libraries, because
the only feature it offers (that isn't already offered by awaitAll) is one that controls
internal implementation details of libraries invoked within the block.
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.
It is, imo, a MAJOR FOOTGUN, and should not be even considered for implementation.
Regards,
Daniil Gentili.