If that were the case. But it isn’t. For example, the Swoole project has existed for more than 7 years. This means that anyone here can check how coroutines actually affect their code. There is already extensive experience with Laravel and other applications. All of this has existed for a long time.
If people cannot read the RFC and understand that these are JavaScript-style coroutines, then why do they have votes? 🙂 That’s a strange idea. Yes, there are issues with understanding. However, a year has passed since the publication. In one year, it should have been possible to clarify any questions, if there were any. In other words, if PHP had never had such coroutines, that could be understood. But the situation is exactly the opposite. As for trust, the problem is that people don’t want to waste their time. They don’t want to play for a team with no chance of success. What can be done? A lot of things can be done. Last time there were several proposals. But all of these proposals go beyond the scope of the RFC. They require organizational changes. I can once again propose having two votes and an experimental mode. The first vote would be on the core principles of the language’s development for the next 5–10 years. A vote on this RFC. Or another option. There is more than one. For example, you could vote in a first approximation, and then a year later in a second round. So... ср, 21 янв. 2026 г., 22:15 Deleu <[email protected]>: > > > On Wed, Jan 21, 2026 at 4:29 PM Edmond Dantes <[email protected]> wrote: > >> Regarding the group, I want to once again express an important point. >> The main problem, the primary blocking issue, is that nobody believes >> this RFC has any real chance. >> >> It’s like in the banking system: if you convince people that stocks >> will fall, then even if it’s not true, the stocks will fall. >> >> At the same time, I agree with this assessment. >> We are facing a paradox. >> >> To make changes to the language, you need to believe that these >> changes can be accepted. Previously, there were doubts about whether >> such changes could even be implemented. That problem has been solved. >> What remains is the lack of trust in acceptance. >> How can this be resolved? I think there are ways, and they are known. >> They are just all outside the scope of the current RFC. >> >> ---- >> Ed >> > > I doubt the problem is about trust. You can trust that a company will not > go bankrupt, you still need to understand how to operate and buy stocks. I > think most readers are more likely to agree that you've put a tremendous > amount of work forward and it's not that hard to trust you've done a great > job so far. But if we don't know how things work, we can't help you make > even better decisions nor can we make use of what you've built. > > I also don't think it's fair to expect from PHP's RFC process a position > of: "trust me, this is the best, lets just merge it". Even if you were the > best and smartest software engineer in the world, PHP is used by an > immeasurable amount of people from all backgrounds, in many contexts and > many approaches. Its not humanly possible for a single individual to know > every possible way PHP is used and the RFC process is here for people from > many backgrounds to provide their own perspective of things and voice how > they think such a change will affect them or their project - be it a > positive or a negative impact. > > Right now, I think the "fairest" assumption is that we don't have many > such voices because nobody can read, understand, interpret and predict how > this RFC would play out in their projects and their work. It's far too big > of a change with too many concepts, mainly foreign to many people working > with PHP and there isn't a clear path of contributing to the discussion. > > How do we solve that? > > -- > Marco Deleu >
