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

> Am 28.05.2026 um 19:14 schrieb mjec <php@mjec.net>: > > I'm not a voter, but I have thoughts. > > On Thu, 2026-05-28 at 11:35 -04:00, Hendrik Mennen <hmennen90@gmail.com > <mailto:hmennen90@gmail.com>> wrote: >> > 1. Extension based parsing isn't a popular idea. The first few >> > responses to this have echoed this, but there's a certain power in >> > allowing the parser to not care about the extension. >> >> Fair, and I have heard this from both Ben and Alex earlier in the thread. My pushback there >> has been that the engine already has the filename available at zend_compile_file and at >> include/require resolution, so teaching it to check the extension is additive rather than >> architecturally violating. > > 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. > >> That said, as a complementary mechanism for explicit override or for stdin/eval cases where >> no filename exists, a require_pure or require_module-style call is genuinely useful. I floated this >> in my reply to Alex as part of a synthesis: extension as primary signal, CLI -p flag for stdin >> (Ben's suggestion), require_pure-family for explicit override (your and Alex's >> suggestion). The autoloader question gets simpler in that synthesis because the autoloader can >> dispatch on extension by default. > > 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. > >> > 4. PHP has several braceless syntax control structure commands - Would >> > these stay around or should they too go away since they aren't >> > really needed in a code first file. > ... >> Two reasonable positions: > ... >> (b) Disallow it. The new file format has the freedom to be stricter, and the alternative >> syntax serves no purpose without templating. > > 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. > >> The accidental-echo / headers-already-sent issue is the real practical win. That bug class >> disappears entirely in pure-code files. I would list this as the second motivation in the RFC after >> the conceptual one. > > 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