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

- Thread: https://externals.io/message/131029
- Original archive: https://news-web.php.net/php.internals/131029
- Started by Ben Ramsey on 2026-05-28T02:31:49+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

---

## #131029 — Ben Ramsey — 2026-05-28T02:31:49+00:00

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

> 
> > […]
> 
> Right, that is the current behavior, and changing it is exactly what the proposal is about. The engine would learn to check the file extension at the entry point (zend_compile_file for SAPI/CLI, and the include/require family for nested loads) and use that to set the initial lexer state. The .php behavior remains untouched.


The behavior right now is that the file extension isn't checked. So, 
whether it's .php, .phtml, .php3, .rb, .py, or .txt doesn't matter. 
Using .php is a convention, not a requirement. If the proposal places 
any restrictions on the file extension, that's a major BC break.

So, the logic will need to be something like: if .phpc, then parse 
assuming there are no <?php tags, otherwise assume there must be <?php tags.


> That said, you point indirectly at something I do need to address: there are entry paths where the engine does not have a filename, or has one it should not trust. Off the top of my head:
> 
> - stdin (cat foo.phpc | php). No filename available. Options: require an explicit CLI flag (php --pure), or simply not support this path and document it.
> - eval(). Operates on strings, not files. Extension is irrelevant here; eval() continues to require <?php as today.
> - Phar archives. Internal entries have filenames, so dispatch by extension should work, but I would need to verify.
> - include of a URL stream (rare, often disabled). Same question. Probably handled by extension on the URL path.
> 
> I will work these out explicitly in the RFC draft. Thanks for surfacing it.
> 
> > […]
> 
> Fair point, and one I had not weighed heavily enough. The Python .pyc parallel is real and would cause exactly the kind of one-time confusion that adds friction to adoption. Boutell's 2012 RFC used .phpp (Pure PHP) for the same purpose, which avoids the bytecode association. I am open to .phpp or other suggestions; the disambiguator matters less than the mechanism.


I'm still unsure about assigning any meaning to the extension. Maybe 
this is something that could be handled at the SAPI configuration level 
similar to how .phps files are configured? Likewise, maybe the CLI 
should have a `-p` flag that tells it to process the input without 
checking for <?php tags.

For what it's worth, `php foo.phps` still executes the file. You need to 
run `php -s foo.phps` to output HTML syntax-highlighted source. The 
.phps extension has no meaning to the interpreter.

That said, I'm not sure how you'd handle this with include/require or in 
Phar files.


Cheers,
Ben