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

- Thread: https://externals.io/message/131043
- Original archive: https://news-web.php.net/php.internals/131043
- Started by Henrik Skov on 2026-05-28T20:57:07+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

---

## #131043 — Henrik Skov — 2026-05-28T20:57:07+00:00

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

Hi internals !

I fail to see the upside ?
What does such a feature provide as an upside to users ?
Is it performance only ? The performance gain would be negible wouldn't it ?

/Henrik


> 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
>
-- 



Med venlig hilsen

Henrik Skov
/HSK Consulting/
Blegdamsvej 128B, 4
DK-2100 Copenhagen O
Tel.: +45 27 62 83 01
Email: henry.wood.dk@gmail.com