Re: [RFC] Pure-code source files via the .phpc extension

On 2026-06-15 20:03, Hendrik Mennen wrote:

Following the pre-RFC discussion from late May [1], I'm moving the "pure-code source files" proposal into formal RFC stage as https://wiki.php.net/rfc/optional_php_tags <https://wiki.php.net/rfc/ optional_php_tags>

The single core motivation is:

Most new PHP files written today are pure code – framework classes, autoloaded library code, console commands, configuration files, route definitions. For these files the '<?php' opener carries no semantic information; it is a vestige of PHP's templating heritage that every file must repeat. PHP is the only modern mainstream language in which this prefix is mandatory.

To which my response is "and that is a bad thing ... how?" On the subject of ceremonial boilerplate ... Maybe it's changed in the years since I had to work with it, but Perl modules had to end with "1;" because they were evaluated as they were imported, and the whole module had to return a truthy value to indicate that it had successfully loaded. (Of course, any truthy value would work and '1' was merely convention - TMTOWTDI.)

The mechanism is a single new opt-in file extension, .phpc, whose semantics are: the file is parsed as pure PHP. The lexer enters ST_IN_SCRIPTING on the first byte; no opening <?php is required. A leading UTF-8 BOM and a CLI shebang are silently skipped. The classic .php extension and every other code-loading path are completely untouched - the change is strictly additive. Reference implementation: PR against php/php-src (link in the RFC). Patch is ~50 lines of straight-line C in Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new .phpt tests in Zend/tests/phpc/. Full regression run against Zend/, ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/ (9836 tests): 0 failures, 0 modifications to any pre-existing test. Pre-RFC feedback, addressed in the RFC document:  - Ben Ramsey on engine-vs-SAPI dispatch:

    own section explaining why include/require/Phar all live below
    SAPI and need engine-level handling. Ben's -p/stdin idea is
    adopted as Future Scope (a sister RFC after this one).

 - Alex Rock on alternatives (env var, include_pure keyword,

    declare(pure=1)): each rebutted individually under "Rejected
    Alternatives".

 - Bruce Weirdan on BC of the .phpc extension itself: own

    paragraph in the BC section, honest about the fact that I have
    NOT scanned public corpora; asking voters with private-codebase
    visibility for data points during Discussion.

 - .pyc visual collision and scattered prior .phpc usage:

    addressed via a sub-vote on the extension name (.phpc / .phpp /
    .pcode / .phpx).

 - Security (source-code exposure via misconfigured webservers,

    the historic .inc footgun): own section with mandatory
    documentation commitments and canonical Apache/Nginx/Caddy/
    FrankenPHP snippets in Appendix A.

 - Boutell 2012 and Ohgaki 2014: own section distinguishing this

    proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward to feedback, especially on:  - The Open Issues block in the RFC (extension name, real-world

    .phpc-in-use data, case-sensitivity on Windows/macOS).

 - Anything in the Phar / OPcache surface I should test more

    thoroughly before voting opens.

 - Whether the Security section's commitments are strong enough. Thanks for reading, Hendrik Mennen [1] https://news-web.php.net/php.internals/131024 <https://news- web.php.net/php.internals/131024>