Am 28.05.2026 um 19:14 schrieb mjec php@mjec.net:
I'm not a voter, but I have thoughts.
- 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
includeissue, 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.
- 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