Hello. > RFC authors are the subject-matter experts for their proposals, and the way > the process succeeds is by the author being willing to explain, restate, > clarify, and anchor concepts for people coming from different backgrounds and > different levels of familiarity.
For the discussion to be constructive, there has to be a shared desire to reach a common goal. It sometimes feels like I am the only one who needs asynchrony :) PHP does not have many options for implementing asynchrony. Why? 1. Colored functions require the language to support two runtimes. For PHP this is an anti-pattern. A single unified runtime is the key feature of the language. 2. Any code with global state inside coroutines will not behave as expected. This is not a property of this RFC but of any asynchronous code. I can add this sentence, but last time I was asked to remove wording that sounded alarming. True Async, Swoole, and Swow follow the same idea. Different implementations, but the same logic. AMPHP and React differ only in that they do not intercept PHP functions, but they still use the same technology, the same algorithms, and the same approach. TrueAsync was originally written with code from AMPHP, so you can see microtasks that AMPHP borrowed from JavaScript. Later, it adopted some techniques from Swoole. In other words, PHP has had a de facto coroutine approach for many years, but no one has ever standardized it. There is an approach and there are implementations, but there is no RFC. Do you understand why this RFC is written the way it is? Why does the RFC state that code does _not need to be changed_? Because in AMPHP and React you cannot simply take your code and run it inside a coroutine. So you must replace all PHP functions with special ones. This does not mean that a developer should forget about memory or corner cases. There is no silver bullet in programming. Do we really need to add a disclaimer under every statement that there are always exceptions? In programming, every statement has exceptions. What about colored functions. I recently explored a hybrid approach. Its logic is relatively simple. The compiler allows writing async next to a function, and then it automatically infects other functions. At the same time there is a special word noasync that prevents the compiler from automatic “infection.” Something similar can be implemented in PHP using attributes or static analysis. This would make the code more predictable while keeping it flexible. This RFC does not conflict with that approach at all, and it can be implemented in the future if there is a desire to make the language stricter.
