On Mon, Jun 15, 2026 at 10:06 AM Hendrik Mennen <[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
>

Hi,

It seems something broke with the formatting in the "What is unchanged"
section.

Reply via email to