I'm not a voter, but I have thoughts.
On Thu, 2026-05-28 at 11:35 -04:00, Hendrik Mennen <[email protected]> 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
