Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131028
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
Date: Wed, 27 May 2026 16:27:52 +0200
References: <DD0DF2CC-1F18-A844-B7B8-B00FA2679A47@hxcore.ol>
 <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol>
 <20260527131921.086BB1A00BD@lists.php.net>
To: internals@lists.php.net
In-Reply-To: <20260527131921.086BB1A00BD@lists.php.net>
Message-ID: <8AE9A269-2E40-42F0-A0F8-C6690B2935FE@gmail.com>
From: hmennen90@gmail.com (Hendrik Mennen)



> Am 27.05.2026 um 15:19 schrieb Ben Ramsey <ramsey@php.net>:
>=20
> On 5/27/26 07:12, hmennen90@gmail.com wrote:
>> Hi internals,
>> I intend to submit an RFC introducing a new file extension for =
pure-code PHP
>> source files (no leading <?php required) and would like to gather =
feedback
>> before drafting.
>> Proposal in brief:
>> Files ending in .phpc would be parsed starting in ST_IN_SCRIPTING =
state. No <?
>> php or ?> tags permitted inside such files. Existing .php files and =
their
>> semantics are completely unchanged. This is purely additive and =
BC-clean.
>> Motivation:
>> PHP's mixed-mode default reflects its 1995 templating origins. Since =
PHP 7+, the
>> language has evolved into a credible general-purpose tool: strict =
types, enums,
>> readonly classes, property hooks, JIT compilation. I personally =
maintain
>> PHPolygon, a CPU-bound 3D engine written in PHP =E2=80=93 a use case =
where the
>> templating heritage is pure ceremony. Other modern uses (CLI tooling, =
queue
>> workers, code generators) share this pattern. A dedicated pure-code =
file format
>> would be a small but meaningful acknowledgment that PHP-as-language =
is now a
>> first-class use case alongside PHP-as-template.
>> Prior art and what's different:
>> I have read both rfc/source_files_without_opening_tag (Boutell, 2012, =
abandoned
>> by author) and rfc/nophptags (Ohgaki, 2014, inactive). My proposal =
deliberately
>> avoids what I believe were the two design choices that killed them:
>> - No new include syntax (Boutell's AS keyword). Extension-based =
detection only.
>> - No php.ini-based mode switch (Ohgaki's template_mode). No global =
config side
>> effects.
>> - No security framing. The mode-switch overhead is parse-time only =
and OPcache/
>> JIT eliminate it in practice; this proposal is about conceptual =
clarity and
>> tooling, not performance or LFI mitigation.
>> Implementation:
>> I will write and maintain the implementation patch. Initial scope: =
extension
>> registration in zend_compile_file, lexer state initialization, =
OPcache
>> awareness, CLI support, and rejection of <?php/?> tokens inside .phpc =
files. I
>> will also coordinate with Composer maintainers ahead of RFC =
submission to
>> confirm autoload support.
>> Open questions for the list:
>> 1. Is the .phpc extension acceptable as the disambiguator, or is =
there appetite
>> for something else (e.g. shebang line, declare directive =E2=80=93 =
both of which I think
>> are worse, but I'd hear the case)?
>> 2. Should #! shebang lines and UTF-8 BOM be permitted before the =
implicit
>> scripting state begins? My intent is yes for both.
>> 3. Should __halt_compiler() retain its current behavior in .phpc =
files? My
>> intent is yes.
>> I welcome substantive critique. If the concept itself is unwanted, I =
would
>> rather know now than discover it during a vote.
>> Thanks.
>> Hendrik Mennen
>> Maintainer, PHPolygon
>=20
>=20
> The problem with assigning meaning to a file extension is that the =
interpreter (currently) doesn't care what the file extension is. As long =
as it's text, it'll process any file and execute what comes after any =
<?php tags.
>=20
> What you want is something like this:
>=20
>    php -r "$(cat foo.phpc)"
>=20
> Of course, this only works for a single file, and the engine won't =
execute code in any included files unless they contain PHP open tags, so =
the file needs a way to tell the engine to parse and execute it as PHP =
source.
>=20
> At the risk of bike-shedding, I think it could be easy for others to =
confuse .phpc files as byte-code files, since it's common to see Python =
byte-code files with the .pyc extension. Also, a lot of folks in the =
community use "phpc" as a shorthand and tag to mean "PHP community," =
though I'm not sure this is reason enough not to use the .phpc =
extension. I don't have any better alternative recommendations at this =
time, though.
>=20
> Cheers,
> Ben


One more Try for readability:

Hi Ben,

Thanks for the quick response.

> The problem with assigning meaning to a file extension is that the
> interpreter (currently) doesn't care what the file extension is. As =
long
> as it's text, it'll process any file and execute what comes after any
> <?php tags.

Right, that is the current behavior, and changing it is exactly what the =
proposal is about. The engine would learn to check the file extension at =
the entry point (zend_compile_file for SAPI/CLI, and the include/require =
family for nested loads) and use that to set the initial lexer state. =
The .php behavior remains untouched.

That said, you point indirectly at something I do need to address: there =
are entry paths where the engine does not have a filename, or has one it =
should not trust. Off the top of my head:

- stdin (cat foo.phpc | php). No filename available. Options: require an =
explicit CLI flag (php --pure), or simply not support this path and =
document it.
- eval(). Operates on strings, not files. Extension is irrelevant here; =
eval() continues to require <?php as today.
- Phar archives. Internal entries have filenames, so dispatch by =
extension should work, but I would need to verify.
- include of a URL stream (rare, often disabled). Same question. =
Probably handled by extension on the URL path.

I will work these out explicitly in the RFC draft. Thanks for surfacing =
it.

> At the risk of bike-shedding, I think it could be easy for others to
> confuse .phpc files as byte-code files, since it's common to see =
Python
> byte-code files with the .pyc extension.

Fair point, and one I had not weighed heavily enough. The Python .pyc =
parallel is real and would cause exactly the kind of one-time confusion =
that adds friction to adoption. Boutell's 2012 RFC used .phpp (Pure PHP) =
for the same purpose, which avoids the bytecode association. I am open =
to .phpp or other suggestions; the disambiguator matters less than the =
mechanism.

> Also, a lot of folks in the community use "phpc" as a shorthand and =
tag
> to mean "PHP community," though I'm not sure this is reason enough not
> to use the .phpc extension.

Noted. Less critical than the .pyc concern in my view, but it does =
reinforce that .phpc is not the obviously-best choice. I will list =
candidate extensions in the RFC and explicitly invite the list to pick =
one rather than defending a specific letter.

Thanks again for the substantive feedback.

Hendrik Mennen
Maintainer, PHPolygon=