>> 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.
When you have a construct that is forcing all code within it to to terminate all running fibers. If any library invoked within a wait_all block suddenly decides to spawn a long-running fiber that is not stopped when exiting the block, but for example later, when the library itself decides to, the wait_all block will not exit, essentially forcing the library user or developer to mess with the internal and forcefully terminate the background fiber. The choice should never be up to the caller, and the presence of the wait_all block gives any caller the option to break the internal logic of libraries. I can give you several examples where such logic is used in Amphp libraries, and it will break if they are invoked within an async 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. >> > 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. You misunderstand: this is about storing the FiberHandles of spawned fibers and awaiting them in the __destruct of an object (the same object that spawned them in a method), in order to make sure all spawned fibers are awaited and all unhandled exceptions are handled somewhere (in absence of an event loop error handler). Also see my discussion about ignoring referenced futures: https://externals.io/message/126537#126661 > >> >> 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? 1) Yes, because it gives users tools to mess with the internal behavior of userland libraries 2) Yes, because (especially given how it's named) accidental usage will break existing and new async libraries by endlessly awaiting upon background fibers when exiting an async {} block haphazardly used by a newbie when calling most async libraries, or even worse force library developers to reduce concurrency, killing async PHP just because users can use async {} blocks. > A FOOTGUN is something that significantly breaks the language and pushes > developers toward writing bad code. This is a rather serious flaw. Indeed, this is precisely the case. As the maintainer of Psalm, among others, I fully understand the benefits of purity and immutability: however, this keyword is a toy exercise in purity, with no real usecases (all real usecases being already covered by awaitAll), which cannot work in the real world in current codebases and will break real-world applications if used, with consequences on the ecosystem. I don't know what else to say on the topic, I feel like I've made myself clear on the matter: if you still feel like it's a good idea and it should be added to the RFC as a separate poll, I can only hope that the majority will see the danger of adding such a useless keyword and vote against on that specific matter. Regards, Daniil Gentili.
