I’ve just submitted to the PHP internals mailing list a new PHP RFC, for a faster-moving, community-driven PHP: https://wiki.php.net/rfc/php-community
With this proposal, the entire PHP community gets immediate access to experimental features through an official php-community version of PHP, versioned in a rolling manner (i.e. php-community 2026.03.01), and available on php.net along normal PHP releases, similar to rust-nightly.
Experimental features are offered as special PHP feature extensions built into PHP by default.
These special feature extensions are versioned with semver and disabled by default, and can be easily enabled with a single PhpFeature::get($name, $version)->enable() call (i.e. automatically invoked by the Composer autoloader).
Feature extensions cannot be enabled using php.ini, to allow enabling features on webhosts: however, to allow for proper sandboxing and thus webhost adoption, a new universal sandboxing level configuration key is added to php.ini, effectively offering the same protection offered by disable_functions et al, for all feature extensions, without the need to search which specific functions to disable.
For the first time, official binaries and packages will be provided for all major Linux distros for php-community releases on php.net (and the usual binary builds for Mac OS and Windows will be provided as well).
This makes it significantly easier to get real feedback on features from the entire PHP community.
The main objective of this RFC is to allow the community to “preview” future language changes in an easily accessible manner: while there have been improvements lately with PIE, experimental language features distributed using normal extensions are still not easily accessible to the entire PHP community; every extra installation step is a barrier to entry, and often simply cannot be installed at all in the most popular PHP execution environment: shared hosts.
To view a full description of the API and how it all works, take a look at the RFC: https://wiki.php.net/rfc/php-community
Side note, I’m now part of the PHP True Async committee!
I decided to not present the RFC as explicitly linked to True Async, to explicitly prevent an interpretation where it is something that will allow us to “sneak in” True Async into PHP.
True Async is one of, but not the only nor the main reason why I created this RFC.
I truly believe that PHP could really benefit from a more agile community RFC process, that can transform it from just a decent and fast language I and so many others love, to an amazing, blazing fast and actually modern and ergonomic language.
I believe PHP truly deserves this.
Let your voice be heard, take part in the discussion for a better future for PHP!
Join in on the discussion using the PHP internals mailing list, or view it in readonly mode using externals.