On Thu, 22 Jan 2026, Edmond Dantes wrote: > > I don't like this experimental model or introducing API stability > > levels as it is confusing for users. It requires extra checking for > > users to do for each API (no one usually does it and with AI it will > > be even more problematic because it might not tell that the > > generated code uses experimental API). This would just become pain > > for user and I don't think it would be good for PHP. > > I think this is a good topic for discussion, and we could talk about > the pros and cons of a “nightly” build. I could explain how early > product delivery improves code quality. > > > That can be already done but it will never guarantee that the second > > vote will succeed.
> It's OK! > > But at least I would know that the PHP community truly wants to make > the language asynchronous. I still don’t understand the answer to that > question. It seems to me: no. I think there is a difference between: 1. Make the PHP language wholly asynchronous 2. Add some (more) asynchronous functionality to PHP From this series of RFCs, I think you believe that 1 is needed, or perhaps *necessary*. On the other hand, I believe that most PHP developers are more interested in the second option — run a few slow things in parallel. There have now been more than half a dozen variants of the RFC, and beyond the amount of work that you put in it, it also asks a lot of everybody else to read and understand. As somebody earlier in these threads explained, the subject matter is also not a simple one, and it requires deep understanding to be able to understand all the trade-offs and consequences. Implementing this project requires is a large undertaking, akin to the Unicode project (PHP 6). That project ultimiately failed because it ended up being too big, with too many trade-offs. Your "True Async" project additionally suffers from only having one main implementor. The Unicode issue got partly resolved by splitting it up into much smaller blocks, in the form of the intl extension, and now in the last few releases with better support for handling graphemes. We have seen the same for PFAs and other langauge additions — this makes it much easier to reason about that, and to get these features adopted. I have said this before, but for a large project like "True Async", you really ought to get a group of people together in a Working Group, to decide what *PHP users* would want this functionality for in a language focussed mainly on web applications. But you approach this from the other side, by wanting to make PHP itself an asynchronous language. I think doing such a large project, mainly by yourself as the sole designed and developer, is doomed to fail. It isn't something I would be confident about voting for, at least. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @[email protected] @[email protected]
