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

- Thread: https://externals.io/message/131041
- Original archive: https://news-web.php.net/php.internals/131041
- Started by Hendrik Mennen on 2026-05-28T18:08:21+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

---

## #131041 — Hendrik Mennen — 2026-05-28T18:08:21+00:00

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

> Am 28.05.2026 um 19:14 schrieb mjec <php@mjec.net>:
> 
> I'm not a voter, but I have thoughts.
> 
> 
> > […]
> 
> It's not purely additive. It's taking a thing that currently has no semantics (filename) and giving it semantics. Without this change, users are able to choose the semantics of the filename by choosing how to invoke the interpreter. After this change, that is no longer guaranteed to be the user's choice.
> 
> > […]
> 
> Even ignoring the `include` issue, this is more evidence to me that the trigger for this mechanism should not live in the filename. Let users choose an invocation path (SAPI configuration) based on filename if they want, but do not make it a language feature.
> 
> > […]
> ...
> > […]
> ...
> > […]
> 
> This would be a big change from the original proposal, which was "pars[ing] starting in ST_IN_SCRIPTING". This is not just talking about skipping `<?php`, you're talking about defining new syntax rules. As you discuss, this is an enormous can of worms, and I wouldn't want it to be tacked onto something that has a different primary purpose. To be honest I would not consider this a reasonable position on this RFC.
> 
> > […]
> 
> I don't think of this issue as big enough to require a language feature. You can already check for this condition with a one-liner without any additional tooling:
> 
> php -r 'echo empty(array_filter(token_get_all(file_get_contents("/path/to/file.php")), fn($t) => $t[0] === T_INLINE_HTML)) ? "OK\n" : "Contains non-PHP!";'
> 
> And finally, Hendrik while I appreciate your detailed replies, they are clearly LLM-patterned, and that makes me disinclined to read them. I understand if you want help crafting the words you use, but I just don't really believe you would have said anything like "[t]his is the most important point you raised and I want to be careful with it" (for example) if that hadn't come from an LLM. That means you're communicating its judgement, not your own. I do not want to start a discussion on this topic, merely to express my view.
> 
> mjec
> 

Hi mjec,

Thanks for your mention about LLM usage - yes I use LLM in my daily work but I’m also a developer at senior level with 10 years of experience - much less than most others :-)

I’m fairly new to PHP Core / Extension development - that’s right. I don’t trust LLM output blindly.


Because of your point „4. PHP has several braceless syntax control structure commands

Yeah - this was out of scope for this RFC but I wanted to address it. - The core of my intention is clear the option to get rid of <?php and ?>

Hendrik