100% agree with Deleu. Edmond, part of the problem you're facing is you aren't just introducing a new feature - you're introducing a paradigm shift. I did an RFC like that once - the introduction of runtime assertions into Drupal - and the discussion around the change took far, far longer than the code - about 6 months. The initial reaction was that such are unneeded in Drupal, after all there's thousands of unit tests. I had to explain that unit tests are for known configurations and that runtime assertions are for the unknown, among other arguments for and against. The RFC was eventually accepted because it provided a means to significantly speed up Drupal by stepping over its development token sanity checks in prod, but it was a stormy journey.
Coming back to your proposal, While I'm very aware of the async pattern from its use in JavaScript and C#, I don't quite get where it will be useful in PHP. My experience with PHP is that it responds to HTTP requests and that stepping over a function that hasn't finished its output isn't helpful because you aren't really saving any time in that request thread as it has very defined start and end points. But we write PHP scripts the way we do because of how the language is structured. Many apps spend a lot of time setting up for the request - Drupal for example has to boot its kernel and part of that is the reading in of an enormous dependency injection map generated from the configuration yaml files of the active modules - that file alone can get into tens of thousands of lines of code. All of that processing work to just be thrown away once the echo back to the server occurs. It would be nice to have a coordinator process that does all this setup work and stays alive handling requests by handing them off to workers. That's how the various C# apps I've seen work. But that sort of setup would require asynchronous code. So I can see a future use case for all of this. But you don't need to convince me - I don't have a vote. Just, don't give up and don't get frustrated. It's hard. You can still read the Drupal discussion on runtime assertions. I got rather testy at times after explaining the same thing for the 12th time. But I didn't take it personal and when my emotions needed checking I'd step away for a few hours. Everyone, It might help to do an RFC just on the principle of adding asynchronous code to 9 without commitment to any particular implementation. Unlike the lofty goal of adding unicode to the language which never panned out and caused us to need to step over 6, Edmond's RFC seems far enough along to prove that it is a doable change for the language in some form. Such an RFC would get Edmond off the clock and relieve some stress of feeling like "I've got to get this approved before the window to submit closes." I know what that window feels like because the PHP runtime assertions addition to Drupal 8 was dead last and only accepted because it provided a solution to an issue blocking release. It would also get the rest of us off the clock as well. This proposal needs very careful consideration as it has wide ranging implications. But it's also the sort of proposal that can't walk in on a minor release, and major release windows are rare. Again, thank you everyone. On Sun, Nov 16, 2025 at 7:17 AM Deleu <[email protected]> wrote: > This thread is a clear, explicit and direct representation that there are > people following all the hard work that you’ve put into this RFC. I dare > say that nobody doubts your intentions, effort and initiative to tackle > such a complex and hard task. > > The next step is to recognize that anybody participating in an RFC > discussion is a person taking time out of their lives, their family, their > work, their hobbies and volunteering their time similar to you. Everyone > has PHP best interest at heart even if what we think is best for PHP > differs. > > On Sun, 16 Nov 2025 at 03:56 Edmond Dantes <[email protected]> wrote: > >> Hello >> >> > Maybe that’s inherent to a subject matter that indeed could be the >> biggest change to PHP since 7, >> > but given RFC voting history, all signs point to a rejection vote. >> >> I think so too. >> >> > I don’t know how much has been discussed off list and/or how many >> voters are involved off list. >> >> There were almost no discussions apart from the one on INTERNALS. I >> mean, there were no discussions that I’m aware of. >> >> I don’t know what to do about a situation where PHP developers are >> surprised to learn that their language has supported transparent >> asynchrony as a core paradigm for several years already. > > > I suppose you’re referring to Swoole, AMPHP, ReactPHP, etc. While there’s > no denying they’re an important part of the ecosystem and living proof > there’s room for asynchronous PHP, your positioning here seems to assume > that everybody participating in your RFC should know, understand and use > one of these projects and have that baseline knowledge. From my personal > experience, context and little bubble, I would guess that less than 10% of > PHP engineers worldwide has any firsthand experience with any of these > tools combined. Your RFC can bridge that gap, but to do so you need to be > able to address why the other 90% hasn’t used any of these existing > approaches. Your target audience is exactly the opposite of what you expect. > > >> And instead of discussing the important details of the RFC, all the >> effort goes into “basic questions” that aren’t worth discussing at >> all. > > > > This is perhaps the most likely reason for the RFC to fail a vote. Let’s > break down voting in an abstract format. Some common reasons voters may > choose to vote NO are: > > - they don’t like the change and don’t want it on PHP > - they disagree with the approach > - the change increases PHP maintenance burden for a subjective benefit > - the RFC is unclear > > There’s not much you can do about 1. And for every NO you get, you need 2 > YES to overcome it. > > My personal guess is that 4 would drive a lot of NO and the reason is a > combination of factors. It’s a very complex and dense RFC and not every > voter will have any experience with the existing async tools provided by > the community. When trying to take time out of their personal lives to go > through such a complex and extensive RFC, basic questions will arise. They > will attempt to address it before going deeper and deeper and will be met > with a dismissive response from the author “because this is too basic and > we shouldn’t focus on it”. They will make the easy choice to not continue > to volunteer their time into something so hard to wrap your head around > since it’s too challenging to even get past the basics. A negative result > is not really a surprise at this point. > > It would be wonderful if there were a dedicated person whom everyone >> would listen to carefully and who could explain the basic questions >> privately. Most likely, this approach would solve many problems. >> >> --- >> Best Regards, Ed > > > Short of forking PHP, that seems like wishful thinking. PHP is driven by > committee and there doesn’t seem to be any way around that. But there are > approaches you can try. > > One of them is pairing it up with someone better at docs, communication, > etc. Take a look at Larry’s RFCs. Majority of it he doesn’t write any C > code, but he makes up for it 10 times by producing clearly readable, > understandable and decision points communicated. Voters may still disagree > at the end, but it always feels like they understand what they’re voting > on/for. > > I don’t know if you’re good with a camera, but going in a podcast with > someone like Brandt, Nuno Maduro or any other PHP podcast that tries to > breakdown internals for easy consumption could also help your cause. > > Ultimately, I think your vast expertise on the matter is both a blessing > and a curse. A blessing because without it maybe the RFC would have never > even existed - at least no other RFC on the matter has reached so far. A > curse because nobody else seems to be able to understand what you’re > saying, what you’re doing and what PHP will be like if your RFC is approved. > > As someone writing PHP for 15 years, I’m scared of bringing any async > community tools to any project I work because I don’t know what would > break. Your RFC states that you want all my code to keep working which is > great, but the moment I make use of something async it could inadvertently > affect something and I don’t know what/why/how. I’m dumb and don’t know how > async works and I don’t want PHP to allow me to shoot myself in the head > like that. Is there anything you can do about it? > > I wish you all the best luck on the RFC and your next steps. I thank you > for all your time so far and I’m eager to see what come out of it. > >>
