> Am 16.06.2026 um 06:52 schrieb Michael Morris <[email protected]>: > > > > On Tue, Jun 16, 2026 at 12:21 AM Hendrik Mennen <[email protected] > <mailto:[email protected]>> wrote: >> >> >>> Am 15.06.2026 um 10:43 schrieb Kamil Tekiela <[email protected] >>> <mailto:[email protected]>>: >>> >>> >>> >>> On Mon 15 Jun 2026, 10:03 Hendrik Mennen, <[email protected] >>> <mailto:[email protected]>> 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.
Hi Michael, Thanks - registered as opposed, conditional on "not bundled with something larger". That conditional is a useful distinction. The "you're closing the door on a bigger one-shot opportunity" framing is worth answering directly. Two reasons I don't think it holds: - .phpc and a hypothetical JS-strict-mode-style language cleanup are best designed as orthogonal axes, not bundled. Strict mode naturally lives in declare() or an attribute - both work inside .php AND .phpc. Coupling "pure code" with "strict mode" would force every .phpc adopter into strict mode whether they want it or not, which is a much bigger ask than "opt into either independently". - PHP already has per-file opt-ins that landed individually - declare(strict_types=1), declare(ticks=1), readonly classes, enums, property hooks. None of them consumed "the one-shot file-mode slot" because there isn't one. .phpc adds one more opt-in along a different axis; it does not consume design space a future strict mode would need. Bundling would make BOTH proposals harder, not easier. Strict mode is contentious by design (every behaviour change has defenders) and would extend Discussion and Voting by months or years. Removing the opener does not have to wait on that. If you have concrete ideas about what a PHP strict mode should contain - which warts, which behaviours, which design - I would be genuinely interested, separate from this RFC. That is a conversation worth having on its own merits, in its own thread. Regards, Hendrik
