> Am 15.06.2026 um 10:43 schrieb Kamil Tekiela <[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
