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

- Thread: https://externals.io/message/131032
- Original archive: https://news-web.php.net/php.internals/131032
- Started by Alex Rock on 2026-05-28T06:36:15+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

---

## #131032 — Alex Rock — 2026-05-28T06:36:15+00:00

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

Le 28/05/2026 à 06:32, Ben Ramsey a écrit :
> 
> > […]
>
> I don't have a strong objection to the engine making this decision, but
> I'd like to hear from others first.
>
> Cheers,
> Ben


I think this can be summarised with this:

  * File extension cannot have a "meaning" for the engine, as the engine
    does not care about it at all in the first place
  * All SAPIs will consider a "normal PHP file" as default input, could
    it be CLI, mod_php for Apache, or anything else (even FrankenPHP)

IMO this means that the default entrypoint for "parsing and executing 
PHP files" for all SAPIs must not change, but /might/ either be 
complemented with a boolean arg for "pure PHP"/"no <?php ?> tags" , or 
the engine must provide another public entrypoint for this that SAPIs 
could implement or not.

An environment variable could be even used for that, and be included in 
the engine by default, so that all existing SAPIs could be updated at 
lower cost, but the variable name would have to be checked in all 
existing Composer packages (something like "PHP_INPUT_PURE=0|1" , or 
similar, TDB anyway), and would only be used for *first included file*. 
Any subsequent call to "include/require" would still behave as before, 
to avoid BC breaks.

And after that, to make use of this feature in userland projects, I 
would suggest an "include_pure" (and its "require" + "_once" variants) 
global keyword, to keep full compatibility everywhere.

WDYT?