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

- Thread: https://externals.io/message/131026
- Original archive: https://news-web.php.net/php.internals/131026
- Started by Ben Ramsey on 2026-05-27T13:19:20+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #131026 — Ben Ramsey — 2026-05-27T13:19:20+00:00

URL: https://externals.io/message/131026#131026

> 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