[RFC] php-community: a faster-moving, community-driven PHP.

On 3/15/26 09:55, Daniil Gentili wrote:

That's why the builds are signed, and the keys used to sign the builds are also signed by other, trusted parties. If the human who builds it introduces any changes, we can trace it directly to them because they signed that build. If their key was compromised, they revoke the key, and the build's signature now shows as valid but using a revoked key, so others know not to trust it. Cheers, Ben

Arguments like these make me increasingly convinced that PhpFeatures should just ship in normal PHP, without a separate distro. Sandboxing offers all the needed security requirements, ensuring shared host adoption while allowing frameworks to rely on feature extensions shipped in normal PHP.

Companies may or may not use those features, it is up to them. What is important is that environments *allow* the usage of feature extensions.

Talking about what the PHP ecosystem needs as a requirement for improvement X will lead us nowhere, and is precisely the reason for this RFC.

Hello

At one time we considered Swoole as the only solution for our task, even though it was a risk. If we had been a startup, I think we would have made a positive decision. I hope no one is seriously considering using experimental features in places where stability is required. We should assume that everyone participating in this discussion is acting in good faith and with sound judgment. --- Ed

On Sun, Mar 15, 2026, at 15:14, Ben Ramsey wrote:

Those statistics also only show you who is using composer. There are many communities that don't use packagist/composer at all or barely. (WordPress comes to mind immediately) — Rob

By treating feature extensions as packages, reporting directly their installation stats as for normal packages. I would not be against introducing opt-in telemetry like in Go to cover cases like WordPress, but given the large adoption of Composer even just packagist would be fine to start.

On Sun, Mar 15, 2026 at 4:46 PM Daniil Gentili <daniil.gentili@gmail.com> wrote:

But we just don't have those resources in security team. As I said we are struggling to handle the current load. Things might improve in 2027 but that's still not clear if we get some extra resources. If we do, we would more likely want to spend it on the current backlog and improve other things though as there is a lot to do. So I just don't think something like this is realistic. Kind regards, Jakub

On Sun, Mar 15, 2026, at 10:45 AM, Daniil Gentili wrote:

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