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