On 5/27/26 07:12, [email protected] 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
