Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131039
Feedback-ID: iea414789:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 28 May 2026 13:14:08 -0400
To: "PHP Internals" <internals@lists.php.net>
Cc: "Hendrik Mennen" <hmennen90@gmail.com>
Message-ID: <671b98c9-b3dc-47d7-84ae-dfba1efa0e26@app.fastmail.com>
In-Reply-To: <11B6D9B0-2555-4FC4-B540-71680315589F@gmail.com>
References: <DD0DF2CC-1F18-A844-B7B8-B00FA2679A47@hxcore.ol>
 <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol>
 <CAEUnE0c3rmxzp1jPRhJK678J+hsHOXuL79cHpkx7fX50e_Ak5A@mail.gmail.com>
 <11B6D9B0-2555-4FC4-B540-71680315589F@gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
Content-Type: multipart/alternative;
 boundary=1a7620e7f9ea5305f6e021fe02b05aad77e73a5b
From: php@mjec.net (mjec)

--1a7620e7f9ea5305f6e021fe02b05aad77e73a5b
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I'm not a voter, but I have thoughts.

On Thu, 2026-05-28 at 11:35 -04:00, Hendrik Mennen <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

--1a7620e7f9ea5305f6e021fe02b05aad77e73a5b
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>I'm not a vo=
ter, but I have thoughts.</div><div><br></div><div>On Thu, 2026-05-28 at=
 11:35 -04:00, Hendrik Mennen &lt;<a href=3D"mailto:hmennen90@gmail.com"=
>hmennen90@gmail.com</a>&gt; wrote:<br></div><blockquote type=3D"cite" i=
d=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>&gt; 1. Extension=
 based parsing isn't a popular idea. The first few</div><div>&gt; &nbsp;=
 &nbsp;responses to this have echoed this, but there's a certain power i=
n</div><div>&gt; &nbsp; &nbsp;allowing the parser to not care about the =
extension.</div><div><br></div><div>Fair, and I have heard this from bot=
h Ben and Alex earlier in the thread. My pushback there has been that th=
e engine already has the filename available at zend_compile_file and at =
include/require resolution, so teaching it to check the extension is add=
itive rather than architecturally violating.</div></div></blockquote><di=
v><br></div><div>It's not purely additive. It's taking a thing that curr=
ently has no semantics (filename) and giving it semantics. Without this =
change, users are able to choose the semantics of the filename by choosi=
ng how to invoke the interpreter. After this change, that is no longer g=
uaranteed to be the user's choice.</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>That said=
, as a complementary mechanism for explicit override or for stdin/eval c=
ases where no filename exists, a require_pure or require_module-style ca=
ll 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 sug=
gestion), require_pure-family for explicit override (your and Alex's sug=
gestion). The autoloader question gets simpler in that synthesis because=
 the autoloader can dispatch on extension by default.</div></div></block=
quote><div><br></div><div>Even ignoring the `include` issue, this is mor=
e evidence to me that the trigger for this mechanism should not live in =
the filename. Let users choose an invocation path (SAPI configuration) b=
ased on filename if they want, but do not make it a language feature.</d=
iv><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D"overflow-=
wrap:break-word;"><div><div>&gt; 4. PHP has several braceless syntax con=
trol structure commands - Would</div><div>&gt; &nbsp; &nbsp;these stay a=
round or should they too go away since they aren't</div><div>&gt; &nbsp;=
 &nbsp;really needed in a code first file.</div></div></blockquote><div>=
...</div><blockquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap:brea=
k-word;"><div><div>Two reasonable positions:</div></div></blockquote><di=
v>...</div><blockquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap:br=
eak-word;"><div><div>(b) Disallow it. The new file format has the freedo=
m to be stricter, and the alternative syntax serves no purpose without t=
emplating.</div></div></blockquote><div><br></div><div>This would be a b=
ig change from the original proposal, which was "pars[ing] starting in S=
T_IN_SCRIPTING". This is not just talking about skipping `&lt;?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 somethin=
g that has a different primary purpose. To be honest I would not conside=
r this a reasonable position on this RFC.</div><div><br></div><blockquot=
e type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>=
The accidental-echo / headers-already-sent issue is the real practical w=
in. That bug class disappears entirely in pure-code files. I would list =
this as the second motivation in the RFC after the conceptual one.</div>=
</div></blockquote><div><br></div><div>I don't think of this issue as bi=
g enough to require a language feature. You can already check for this c=
ondition with a one-liner without any additional tooling:</div><div><br>=
</div><div>php -r 'echo empty(array_filter(token_get_all(file_get_conten=
ts("/path/to/file.php")), fn($t) =3D&gt; $t[0] =3D=3D=3D T_INLINE_HTML))=
 ? "OK\n" : "Contains non-PHP!";'<br></div><div><br></div><div>And final=
ly, Hendrik while I appreciate your detailed replies, they are clearly L=
LM-patterned, and that makes me disinclined to read them. I understand i=
f you want help crafting the words you use, but I just don't really beli=
eve you would have said anything like "[t]his is the most important poin=
t you raised and I want to be careful with it" (for example) if that had=
n'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.</div><div><br></div><div>mjec</div><div><br></div></bod=
y></html>
--1a7620e7f9ea5305f6e021fe02b05aad77e73a5b--