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

On 5/27/26 07:12, hmennen90@gmail.com wrote:

Hi internals, I intend to submit an RFC introducing a new file extension for pure-code PHP source files (no leading <?php required) and would like to gather feedback before drafting. Proposal in brief: Files ending in .phpc would be parsed starting in ST_IN_SCRIPTING state. No <? php or ?> tags permitted inside such files. Existing .php files and their semantics are completely unchanged. This is purely additive and BC-clean. Motivation: PHP's mixed-mode default reflects its 1995 templating origins. Since PHP 7+, the language has evolved into a credible general-purpose tool: strict types, enums, readonly classes, property hooks, JIT compilation. I personally maintain PHPolygon, a CPU-bound 3D engine written in PHP – a use case where the templating heritage is pure ceremony. Other modern uses (CLI tooling, queue workers, code generators) share this pattern. A dedicated pure-code file format would be a small but meaningful acknowledgment that PHP-as-language is now a first-class use case alongside PHP-as-template. Prior art and what's different: I have read both rfc/source_files_without_opening_tag (Boutell, 2012, abandoned by author) and rfc/nophptags (Ohgaki, 2014, inactive). My proposal deliberately avoids what I believe were the two design choices that killed them: - No new include syntax (Boutell's AS keyword). Extension-based detection only. - No php.ini-based mode switch (Ohgaki's template_mode). No global config side effects. - No security framing. The mode-switch overhead is parse-time only and OPcache/ JIT eliminate it in practice; this proposal is about conceptual clarity and tooling, not performance or LFI mitigation. Implementation: I will write and maintain the implementation patch. Initial scope: extension registration in zend_compile_file, lexer state initialization, OPcache awareness, CLI support, and rejection of <?php/?> tokens inside .phpc files. I will also coordinate with Composer maintainers ahead of RFC submission to confirm autoload support. Open questions for the list: 1. Is the .phpc extension acceptable as the disambiguator, or is there appetite for something else (e.g. shebang line, declare directive – both of which I think are worse, but I'd hear the case)? 2. Should #! shebang lines and UTF-8 BOM be permitted before the implicit scripting state begins? My intent is yes for both. 3. Should __halt_compiler() retain its current behavior in .phpc files? My intent is yes. I welcome substantive critique. If the concept itself is unwanted, I would rather know now than discover it during a vote. Thanks. Hendrik Mennen Maintainer, PHPolygon

The problem with assigning meaning to a file extension is that the interpreter (currently) doesn't care what the file extension is. As long as it's text, it'll process any file and execute what comes after any <?php tags. What you want is something like this:

    php -r "$(cat foo.phpc)"

Of course, this only works for a single file, and the engine won't execute code in any included files unless they contain PHP open tags, so the file needs a way to tell the engine to parse and execute it as PHP source. At the risk of bike-shedding, I think it could be easy for others to confuse .phpc files as byte-code files, since it's common to see Python byte-code files with the .pyc extension. Also, a lot of folks in the community use "phpc" as a shorthand and tag to mean "PHP community," though I'm not sure this is reason enough not to use the .phpc extension. I don't have any better alternative recommendations at this time, though. Cheers, Ben