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
