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

- Thread: https://externals.io/message/131151
- Original archive: https://news-web.php.net/php.internals/131151
- Started by drealecs@gmail.com on 2026-06-05T07:04:28+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

---

## #131151 — drealecs@gmail.com — 2026-06-05T07:04:28+00:00

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

On Fri, Jun 5, 2026 at 9:07 AM Casper Langemeijer <langemeijer@php.net>
wrote:

>
> I think this adds a lot of complexity, for dubious benefit: not having
> to start PHP code files with "<?php".
>
>
> Question - what is the performance hit of scanning the file for <?php and,
> if none are found, restarting the parse process in code mode?
>
> If the hit isn't significant, this might be a way forward. There is the BC
> break that files fed through the parser with nothing to parse will start
> creating errors, but that situation (a php file with no <?php at all) feels
> like an error state anyway.
>
>
> As most projects use dynamic autoloading you'd have to add a stat call for
> a second filename, to try both .php and .phpc files. The performance hit
> for that is much bigger than any minuscule gain.
>
>
I would expect that most projects in production are using composer, and
that they are using the optimized autoloader when installing in production.
That builds a class map to exact file, and no stat call is done.
I would say this is a problem that can be solved at autoloader level, and I
recall I did a similar implementation with what composer does, 10+ years
ago, when not yet using composer.

-- 
Alex