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

> Am 16.06.2026 um 06:52 schrieb Michael Morris <tendoaki@gmail.com>: > > > > On Tue, Jun 16, 2026 at 12:21 AM Hendrik Mennen <hmennen90@gmail.com <mailto:hmennen90@gmail.com>> wrote: >> >> >>> Am 15.06.2026 um 10:43 schrieb Kamil Tekiela <tekiela246@gmail.com <mailto:tekiela246@gmail.com>>: >>> >>> >>> >>> On Mon 15 Jun 2026, 10:03 Hendrik Mennen, <hmennen90@gmail.com <mailto: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 >>> >>> >>> I tried to catch up on this discussion last night. I see a lot of things that could go wrong with this, but I don't see a clear motivation for why would we want this change. >>> >>> Reduced ceremony in pure-code files. >>> This is a moot point because after the change you still have the ceremony of adding .phpc to every file. Just unnecessary churn. >>> >>> First-class CLI scripts. >>> Is this really a big concern? Is it going to work better? Are there things you cannot do today because of it? >>> >>> Clearer file-mode intent. >>> We already have that. By convention many people add .php extension to pure PHP files, and .phtml to templates. It's not mandated by a language and people are free to choose their naming conventions. >>> >>> Strictly additive. >>> That's not entirely true, but that's beside the point. Why is this one of the main motivations? We don't add things just because we can. They need to have a purpose. >>> >>> >>> We already have a good way of writing pure PHP code files. Just add 5 characters at the beginning of the file <?php and the rest of the file will be treated as PHP source code. >>> >>> I would also like to echo what others said that PHP source code doesn't have to be within <?php. A text file will be compiled and interpreted by PHP as a print statement. Even in pure PHP code files you may want to escape the PHP context with ?>. Mandating that a file with a certain extension will have these restrictions is worse than having to start every file with <?PHP. >>> >>> Regards, >>> Kamil >> >> Hi Kamil, >> >> Thanks for the substantive pushback - these are exactly the right >> questions, and you're correct on more of them than the RFC as currently >> worded admits. >> >> Conceding upfront: "strictly additive" is a necessary property, not a >> motivation. I leaned on it too much. Same for the three weaker arguments >> (CLI ergonomics, convention clarity, ceremony shift) - none of them >> alone justifies the mechanism. >> >> The honest single-sentence motivation: >> >> Most new PHP files written today are pure code (framework classes, >> autoloaders, console commands, configuration). For those files the >> <?php opener carries zero semantic information. PHP is the only >> modern mainstream language where it is mandatory. >> >> If that friction is not worth solving, that is a legitimate position >> and I would rather hear that than dress the proposal up to look >> weightier than it is. Three honest paths from here, and I would find >> it useful if respondents could say which they are closest to: >> >> 1. The friction is real and a small targeted addition is worth >> shipping. (what the RFC proposes) >> 2. The friction is real but the mechanism is wrong. (in which case: >> what signal would you prefer? per-file declare, magic first line, >> SAPI-only, ...) >> 3. The friction is not real, or not worth a language change at all. >> >> That is a sharper question than re-litigating each motivation in turn, >> and the answer determines whether to refine, pivot, or withdraw before >> voting. >> >> On your last point - that .phpc "restricts" PHP's text-as-print >> feature - I think we agree more than disagree. .phpc would not change >> .php behaviour at all. It is opt-in by filename. Authors who want the >> templating shape keep using .php, ?> drop-out continues to work inside >> .phpc, and the engine on existing files is byte-for-byte identical. >> The "restriction" you describe (no top-of-file inline content; >> <?php-as-tag rejected inside .phpc) is intentional - it is what makes >> the mode meaningful for the cases that opt in. >> >> I will update the RFC's Motivation section to reflect this >> clarification in the next day or two so the rest of the Discussion >> runs on the stronger framing rather than the weaker one I shipped >> with. >> >> Thanks again, >> Hendrik >> > > I don't get a vote, but mark me as opposed. If we ever do this, it needs to accompany something akin to JavaScript's strict mode which shards off several long standing warts that can't otherwise be gotten rid of because of BC. If we ever do a strict mode we'd better get it right and do it only once. > > As it stands, there just isn't anything here other than lifting the need to type 5 characters at the start of every file. Worse, it could be closing a door we'll never see again.

> Am 16.06.2026 um 09:26 schrieb Davey Shafik <me@daveyshafik.com>: > >> On Jun 15, 2026, at 21:25, Hendrik Mennen <hmennen90@gmail.com> wrote: >> > <snip> >> >> If that friction is not worth solving, that is a legitimate position >> and I would rather hear that than dress the proposal up to look >> weightier than it is. Three honest paths from here, and I would find >> it useful if respondents could say which they are closest to: >> >> 1. The friction is real and a small targeted addition is worth >> shipping. (what the RFC proposes) >> 2. The friction is real but the mechanism is wrong. (in which case: >> what signal would you prefer? per-file declare, magic first line, >> SAPI-only, ...) >> 3. The friction is not real, or not worth a language change at all. > > I am strongly in camp 3; I see zero value in this. > > Adding meaning to a specific extension is a BC break when no extensions have meaning prior. In addition, it makes it difficult to identify the file type from the code alone if you're not familiar with it. > > There really isn't any friction here, any decent editor or IDE will give you a default file header with the open tag (at least). At worst they'll auto-complete after at most 2 characters. > > It's also important to note that other languages have explicit template files like Jinja or ERB, PHP does not have this and is itself essentially both the template language and the full programming language. > > Yes it's a legacy way of doing things like ASP classic or ColdFusion, but that doesn't make it wrong or bad. > > - Davey

> Adding meaning to a specific extension is a BC break when no > extensions have meaning prior.

> It makes it difficult to identify the file type from the code > alone if you're not familiar with it.

> There really isn't any friction here, any decent editor or IDE > will give you a default file header with the open tag

> Other languages have explicit template files like Jinja or > ERB, PHP does not have this and is itself essentially both the > template language and the full programming language. [...] Yes > it's a legacy way of doing things like ASP classic or > ColdFusion, but that doesn't make it wrong or bad.