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

On Mon, Jun 15, 2026 at 10:06 AM Hendrik Mennen <hmennen90@gmail.com> wrote: > Hi internals, > > 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 > > 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 > Hi, It seems something broke with the formatting in the "What is unchanged" section.