On Sun, Mar 15, 2026, at 10:45 AM, Daniil Gentili wrote:
Except feature owners won't be able do any triaging, security impact analysis (deciding whether it's a security issue - this is done by the security team), allocating CVE's, test the patches in our security repo, do the security release and publishing / updating all advisories. And I'm not even considering extra reporting will be required by CRA. So I think you might be underestimating the amount of work for handling security issues.
I do not underestimate it, I simply do not consider it to be a problem,
given the context of PHP needing a LOT of new features in order to
compete with modern languages.
Userland has been pollyfilling them left and right (static analysis,
amphp), but this is not the way forward.
A serious discussion needs to be done around a simple question.
Does internals want to keep PHP mostly as-is, in de facto maintainance
mode (just security fixes, no expensive major features) to reduce the
workload on maintainers, and slowly creep into irrelevance?
Because this is, put bluntly, what is being proposed.
Calling the status quo "de facto [maintenance] mode" is either a statement of total ignorance, trolling, or just being offensive. I will allow others to decide which they feel it is. We routinely have static analysis maintainers objecting to how FAST the language moves, not how slow. PHP is one of the most rapidly evolving languages on the market (at least of those that have actual market share and use and aren't still pre-release experiments).
Those new features may not be the ones you personally would prioritize, but it is patently absurd to call PHP in "maintenance mode." Even a cursory glance at the changelog for 8.5 and 8.4 will show many significant new feature additions from many people, often inspired by other languages to "close the gap" with those languages. Just because someone disagrees with your "php-unstable" proposal doesn't mean they're against the language improving. Come on, you're better than that.
As to the proposal itself, aside from the many logistical and governance issues that others have pointed out already, there's a more fundamental problem that Ben raised and seems to have been dismissed: It simply won't work.
Let's look at a concrete example: The Asymmetric Visibility RFC.
First problem: This feature involved adding new syntax to the language that wasn't just sugar for some other syntax. That means changes to the syntax definition, to the compiler, and to the runtime engine. None of those are especially "pluggable" right now. So an easily enabled/disabled extension would simply not be able to do it. It would have to be effectively a fork, at minimum of the .y file that drives the parser. And syntax changes are the types of PR that tend to have merge conflicts most often, because there's a lot of "index of stuff" files that need to be updated, and two parallel RFCs almost certainly will collide. That means a fork with lots of conditionals in it to disable the syntax. We're talking feature flags, not extensions.
Now, feature-flags aren't a bad thing; They can be quite useful. But they do add complexity, and it means maintaining php-community as a separate branch/repo/whatever from php-src:master is going to be an ongoing problem, just at a basic git merge level.
If we were talking about a different feature that could be fully contained to an extension... then we already have a way to pre-release those: It's called extensions. If we had wanted to, for example, ship ext/Random as a stand-alone random extension via pecl/pie for a while first to get feedback on the API, that's already possible today. Just release an extension and tag it alpha, and then later on we can copy it into php-src when we decide it's ready. No changes needed.
Second problem: What data would have benefited the aviz RFC? There's two possibilities:
1. Would you actually use this?
2. Is this the syntax/semantics that work for you?
Both of these fail for the same reason: The feature *is not yet locked down, by definition*.
There was a lively (and entirely valid and useful) discussion on aviz about what syntax to use. Let's suppose that we released a php-community version of aviz that used the public:private style syntax, to see what happens. Then we'd want to see if we should shift that to public private(set) (as we ended up using).
As Ben pointed out, nobody is going to use it in production. It would be foolish for them to do so, because we're explicitly saying "we could change the syntax for this next month, fair warning." I certainly wouldn't use it for anything more than noodling around on my laptop a bit. I wouldn't even use it in my casual OSS work if I knew it was subject to change. Organizations that rely on PHP as enterprise-critical already have to be cajoled and prodded and begged to update to new *stable* versions of PHP. There won't be any meaningful usage of php-syntax-unstable outside of devs futzing around on their own laptops. So however the telemetry is collected (via Packagist or otherwise), the data will be largely useless for telling us how likely it is that a feature would have widespread adoption once stable (for some definition of widespread).
That also means that feedback on the syntax/semantics couldn't really be trusted, because it's not getting the "real world" use that is desired. And that sort of feedback ("The colon is clumsy, I'd prefer the parens" or vice versa) is not something telemetry would even be able to provide. It would require real people coming to Internals (either the list or GIthub or whatever) and writing words to tell us that. Which... is already the case.
Now, let's look at the opposite problem. Suppose people *do* start using the pre-release aviz for serious work, and it's running in prod somewhere. Then we determine "actually, we really do want to support more operations than just get/set, so we have to use the parens syntax so we can put words other than 'set' in there." Except... crap, if we do that, we'll break all of those production sites that are running with the colon version. So now we can't change it, even though it's an unstable feature. If we did, it would break a bunch of people's production sites. That would be... extremely bad for PHP's image and adoption in business.
Of course, we have the same problem today with stable releases: Once something ships, we can't change it anymore without breaking prod. So we're stuck with it. So either a community-prerelease feature is not used, and we get no meaningful data, or it does get used and then we're stuck with the current form of it, which is no different from today with stable releases. At best, we gain nothing.
We've seen that pre-release syntax can backfire, badly. The best example is CSS: There was a time when browsers would put out pre-release versions of syntax, with a prefix: -webkit-border-radius and such. But then... anyone who used that property in prod needed it to be there forever. You only get to define how -webkit-border-radius works once. You could define -ie-border-radius differently, perhaps, but that was bad for everyone as now they needed to deal with two different syntaxes that may work differently, or worse, don't work differently but you still have to repeat them. That whole approach was eventually declared a failure and abandoned.
We ran into this when developing PSR-14, too. At one point, we had three separate package repositories when there was a harder separation between bidirectional and unidirectional events. Eventually we redesigned it to have no such distinction and cut back down to a single repo, which is what became the official spec. Some time later I deleted the other repos as unnecessary... and someone showed up in our GitHub issues furious that we had broken their site because they were using those temporary 0.4-tagged repositories in their application! No one wins in that situation.
What CSS does now instead is, er, really intensive collaboration and planning (like we do), and then releasing pre-release features behind client-side feature flags. Meaning using a pre-release feature in production is, well, kinda pointless, because 99.9% of viewers of your site will not have that secret flag enabled, so wouldn't see it anyway. It's only useful for the developer to noodle around on their own machine and get enough of a feel for it to give meaningful feedback. And *that* is valuable.
So the actually useful goal here, if we want better quality feedback, isn't to have a quasi-supported "PHP with features that we may or may not break later." It's to make it easier for devs to noodle with the proposal locally to get their hands dirty. 3v4l has a feature that lets you run code snippets against certain PR branches, but that is very manual and selective so only of limited use.
A much, much more useful approach would be to devise some way to automatically build docker images out of PRs against php-src. So if you download the php-dev-aviz-2024-03-10 docker image, it's easy to run it and see what the code "feels like," but no one is going to mistake it for a stable, production-usable image they can build a business on. (Well, almost no one; I'm sure someone will try, but it's a lot easier then to say "it's your own damned fault for running some rando PR in production".)
That would allow devs to more easily "try out" a feature and report back manually. That potentially improves the quality of feedback from "I read the syntax in the RFC and I don't like X" to "I tried writing a class with this syntax and I kept mistyping it because it's fugly". Or perhaps not, but at least it is vastly lower effort to do. The Async people are already doing this, which is very good! All we need is make that easier and more automated to do for any RFC.
I want the async work to succeed. I have ample issues with the current proposal, but it is still the best proposal we've had to date for async and I want it to continue to evolve into something we can ship. But that doesn't mean creating a mess of land mines and useless telemetry and a lot of extra work for maintainers, paid or volunteer.
I have been a very outspoken critic of the current RFC process for many reasons. I do appreciate the interest in adapting it to make it better. But any such proposal should actually make it, well, better. Not more cumbersome and involved for maintainers for no meaningful return on investment.
--Larry Garfield