Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131063
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <11B6D9B0-2555-4FC4-B540-71680315589F@gmail.com>
Date: Fri, 29 May 2026 12:26:26 -0400
Message-ID: <CAEUnE0f7iPyLaLtE1jyL2yor4kA6U21oiDKX9+XQOJGwz6jgwQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000233f380652f74fe8"
From: tendoaki@gmail.com (Michael Morris)

--000000000000233f380652f74fe8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 28, 2026 at 11:35=E2=80=AFAM Hendrik Mennen <hmennen90@gmail.co=
m> wrote:

>
>
> 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 architecturall=
y
> violating. But I take the point that this is a cultural preference on the
> list, not just a technical one. If there is a workable alternative that
> does not have the caller-vs-author inversion problem I raised in my reply
> to Alex, I am open to it.
>

I can't think of one to be honest. The parser needs to know how to handle
the file. That's going to come in the form of the extension or in the
calling statement from within PHP. Any extension choice comes with the
potential BC break that someone, somewhere out there has used that
extension before.


>
> > 6. I would caution against any code only include being implemented
> >    without taking the opportunity to fix certain bugs that have gotten
> >    to stick around because of the enormous BC breaks such fixes
> >    introduce. There are no existing files in this format, therefore no
> >    existing code to have a BC break. This is a rare opportunity to
> >    clean some things that should not be passed on. Please, Please look
> >    into this as part of this.
>
> This is the most important point you raised and I want to be careful with
> it. You are right that introducing a new file format is a once-in-a-decad=
e
> opportunity to ship semantics that would otherwise be blocked by BC. Your
> Modules proposals have been built around exactly this argument, Hack took
> the same route, and the temptation to bundle improvements is real and
> well-founded.
>
> My reservation is purely tactical: every additional semantic change is an
> additional reason a voter might decline. An RFC scoped to "new file forma=
t
> that starts in scripting state" is already non-trivial to defend. An RFC
> scoped to "new file format with stricter type juggling, no eval, no
> variable variables, automatic strict_types, no @ suppression" is a
> substantially harder sell, and the list has a history of preferring focus=
ed
> RFCs over Christmas trees. I want to avoid the derailment pattern.
>
> I think the right approach is to surface this in the RFC text as an
> explicit Open Question: "Should pure-code files differ from .php files in
> semantics beyond the entry parsing state, and if so, in which specific
> ways?" Rather than committing to a list now, I would let the list propose
> specific cleanups and only include those that have clear consensus.
>
> Given your years of iteration on this concept, you almost certainly have =
a
> more grounded list of candidate cleanups than I do. Would you be willing =
to
> share which specific bugs or semantic issues you had in mind? Some that
> come to my own mind: automatic declare(strict_types=3D1), banning variabl=
e
> variables, banning @ error suppression, banning the global keyword. But I
> would value your concrete examples more than my abstract candidates.
>

Those would be a good start. I don't know of any others offhand because I
don't know the engine. I'd have to dig around in the rfc archives to find
other examples.

There's a bit of a quandary here - just removing the need for the <?php ?>
markup doesn't come with enough upside to be justified on its own in my
opinion. It might be doable with the requirement that if a php file doesn't
start with <?php it must instead start with the namespace declaration, but
is this worth the potential confusion.

This honestly would need to be part of a larger syntax cleanup effort for
the benefit of both the engine and the users. The largest single wart in
PHP syntax is the having three scope operators ( \, ->, :: ) where its
sister languages get by with only one ( . ) which PHP uses for a different
operation.  But I believe that runs into similar problems as the reason why
PHP requires $ to lead all variables, it has to do with how the engine
handles these symbols.  I suspect that some of these problems are
intractable and even if they can be solved the performance hit in solving
them might be severe. If that isn't the case (or isn't the case anymore)
then those structures too would be worth review.

This rounds back to a weakness of the RFC process - it works best for small
to medium scope changes. Decisions on large architectural paths are more
difficult (but not impossible).

I got quiet on modules because I don't have the skill to follow it through,
or the time to develop those skills. I was working with Rowain on a
possible path last year, but got distracted by work and dropped the ball.
The problem scope for that, though closely tied to this, is uncomfortably
large.

--000000000000233f380652f74fe8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 28,=
 2026 at 11:35=E2=80=AFAM Hendrik Mennen &lt;<a href=3D"mailto:hmennen90@gm=
ail.com">hmennen90@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><br><div><br></div><div>Fair, and I have heard =
this from both Ben and Alex earlier in the thread. My pushback there has be=
en 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. But I take the point that =
this is a cultural preference on the list, not just a technical one. If the=
re is a workable alternative that does not have the caller-vs-author invers=
ion problem I raised in my reply to Alex, I am open to it.</div></blockquot=
e><div><br></div><div>I can&#39;t think of one to be honest. The parser nee=
ds to know how to handle the file. That&#39;s going to come in the form of =
the extension or in the calling statement from within PHP. Any extension ch=
oice comes with the potential=C2=A0BC break that someone, somewhere out the=
re has used that extension before.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><br></div><div>&gt; 6. I would cautio=
n against any code only include being implemented</div><div>&gt; =C2=A0 =C2=
=A0without taking the opportunity to fix certain bugs that have gotten</div=
><div>&gt; =C2=A0 =C2=A0to stick around because of the enormous BC breaks s=
uch fixes</div><div>&gt; =C2=A0 =C2=A0introduce. There are no existing file=
s in this format, therefore no</div><div>&gt; =C2=A0 =C2=A0existing code to=
 have a BC break. This is a rare opportunity to</div><div>&gt; =C2=A0 =C2=
=A0clean some things that should not be passed on. Please, Please look</div=
><div>&gt; =C2=A0 =C2=A0into this as part of this.</div><div><br></div><div=
>This is the most important point you raised and I want to be careful with =
it. You are right that introducing a new file format is a once-in-a-decade =
opportunity to ship semantics that would otherwise be blocked by BC. Your M=
odules proposals have been built around exactly this argument, Hack took th=
e same route, and the temptation to bundle improvements is real and well-fo=
unded.</div><div><br></div><div>My reservation is purely tactical: every ad=
ditional semantic change is an additional reason a voter might decline. An =
RFC scoped to &quot;new file format that starts in scripting state&quot; is=
 already non-trivial to defend. An RFC scoped to &quot;new file format with=
 stricter type juggling, no eval, no variable variables, automatic strict_t=
ypes, no @ suppression&quot; is a substantially harder sell, and the list h=
as a history of preferring focused RFCs over Christmas trees. I want to avo=
id the derailment pattern.</div><div><br></div><div>I think the right appro=
ach is to surface this in the RFC text as an explicit Open Question: &quot;=
Should pure-code files differ from .php files in semantics beyond the entry=
 parsing state, and if so, in which specific ways?&quot; Rather than commit=
ting to a list now, I would let the list propose specific cleanups and only=
 include those that have clear consensus.</div><div><br></div><div>Given yo=
ur years of iteration on this concept, you almost certainly have a more gro=
unded list of candidate cleanups than I do. Would you be willing to share w=
hich specific bugs or semantic issues you had in mind? Some that come to my=
 own mind: automatic declare(strict_types=3D1), banning variable variables,=
 banning @ error suppression, banning the global keyword. But I would value=
 your concrete examples more than my abstract candidates.</div></blockquote=
><div><br></div><div>Those would be a good start. I don&#39;t know of any o=
thers offhand because I don&#39;t know the engine. I&#39;d have to dig arou=
nd in the rfc archives to find other examples.</div><div><br></div><div>The=
re&#39;s a bit of a quandary here - just removing the need for the &lt;?php=
 ?&gt; markup doesn&#39;t come with enough upside to be justified on its ow=
n in my opinion. It might be doable with the requirement that if a php file=
 doesn&#39;t start with &lt;?php it must instead start with the namespace d=
eclaration, but is this worth the potential confusion.</div><div><br></div>=
<div>This honestly would need to be part of a larger syntax cleanup effort =
for the benefit of both the engine and the users. The largest single wart i=
n PHP syntax is the having three scope operators ( \, -&gt;, :: ) where its=
 sister languages get by with only one ( . ) which PHP uses for a different=
 operation.=C2=A0 But I believe that runs into similar problems as the reas=
on why PHP requires $ to lead all variables, it has to do with how the engi=
ne handles these symbols.=C2=A0 I suspect that some of these problems are i=
ntractable and even if they can be solved the performance hit in solving th=
em might be severe. If that isn&#39;t the case (or isn&#39;t the case anymo=
re) then those structures too would be worth review.</div><div><br></div><d=
iv>This rounds back to a weakness of the RFC process - it works best for sm=
all to medium scope changes. Decisions on large architectural=C2=A0paths ar=
e more difficult (but not impossible).</div><div><br></div><div>I got quiet=
 on modules because I don&#39;t have the skill to follow it through, or the=
 time to develop those skills. I was working with Rowain on a possible path=
 last year, but got distracted by work and dropped the ball. The problem sc=
ope for that, though closely tied to this, is uncomfortably large.</div></d=
iv></div>

--000000000000233f380652f74fe8--