Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:131036 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id BB7CB1A00BC for ; Thu, 28 May 2026 15:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1779981579; bh=M+SR1ieRnwooCX5pWA4whlskgaDNJSV7DI+QX46sIQc=; h=References:In-Reply-To:From:Date:Subject:To:From; b=nbih2J5+VznjZjMu5jxzMwwfo8SVbDDVOASrDb1Kb/Zz5zY6B8yogYr9cEDATXS5o HDSuL1loka5qqx9cNcd4+rwc4D61F9xoaSJ06icNMk7a7qxhktgkDGT0XyC4uBZ0le iMgDojAXKodRJFppDDTS0aJYBVoG+OMEL3FCEY79jUcVlCqsZBL5Ri/dWt8TQvP4ZR 4rksuRBPYvGFcP/tsjs0p8f+DRYX1PBMcrOI4GHbUZG76+k6uAgWtT9MMY6hSo+Is/ E4Hm0bzEuzh5iNWkNAYVTjAur7WTM7dnkB0wwAQmmVnO9hP2dCy0IdqxJTMNkOcbVn sqKuViVsiTPGQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4D32A180083 for ; Thu, 28 May 2026 15:19:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FORGED_GMAIL_RCVD, FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 28 May 2026 15:19:35 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-39393ec4ed0so114623981fa.0 for ; Thu, 28 May 2026 08:19:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779981568; cv=none; d=google.com; s=arc-20240605; b=FUu+qfnlblGvY02e3GFJXS7xP8LsVUk3HRjiQH5jL46pLWUyhOTW8TxzufcW900Za/ KjcT4N4zxUCHW0hudH0FEdQlFO348+grgKsqdlhWspDf60xWco5CWzfVnxurVBAuPGIC YMslf+3al9lc/jxlvumR/6jEfE1WKEKWQ2eAwc4ugWYFVfVnJ0u3BdzkPB46QiegrlJq CTsBENCrZHLqYdwsXpeEjUYYojaj2WrcF9PtJSv0AV4Huv97CdX/ZVp8kGOwKThzl7Ri 3PEgXOxPSa5RGr/tiadlakKDti1mn/uwfB2Az4F7AgqEeegOwyBgMb/TKl6mmhr/2VPI odqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=M+SR1ieRnwooCX5pWA4whlskgaDNJSV7DI+QX46sIQc=; fh=PwvV1jWZOR90rDIG/6XexqaHJyAFBTdnFVhsS64qdEQ=; b=ZcYjRxAR1q9+pmDTkUhshvE5By0hUWnhKafgtzDEdxh7+IE5AUQod6NM7qZDDPTLBi b5vozbIbyOYmI415A/hWSLLAYzQuLP7ArN0u+dUpzrKIDnJnQ3K5NmuEXNIp5aJpV1Z4 82NCzFIajtwWukJT9S8ZPQXy9Nv22hkw497MqE52FASyDBNxUv2F5LUZD+EvfLQs/zTl rCpSkE7hTZxB9qc7BWKjfyFa1RuYJICpjwc+mCZnagAFnvrIopy6bk1mHtAGq1hcoZQD bK917CtCineM0dkDndMLFpiUxRSLEqDl24jGZz6q6YSfQBwesTSRw7pG4zY/B2bzensm DbWg==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779981568; x=1780586368; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=M+SR1ieRnwooCX5pWA4whlskgaDNJSV7DI+QX46sIQc=; b=sOn1i4XVOrdrp/A+cU5P8ZYkSnpu3eoO4ouRdjU64wkiGfN+MKhor8cQiqbKgNvpg5 dfVdGUCyjseEezkQMSKMZ2PKIpXBBsndYjX7da1m0RmYLaZxhiUSwK/ttWYwFk6Jo2Dq kz58Qz0HY5FDGpbqE2gaLnBpsJA2p53rJpVrxGJljREWhYfPTw0ImrDIBbzF8e8QscvC JBK47HEstwkd8kHBD1NWAnm6EFi76dBL20lcAPaa1HWdpPgi7vGfQE8jxM1vwW5FqOU8 AnqzPmk5qk476gLniTd6CjoevZWEAXcSoo4/cmfoIAFyUUkUMVJ9nu/fwN+WPAicglIO ongA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779981568; x=1780586368; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M+SR1ieRnwooCX5pWA4whlskgaDNJSV7DI+QX46sIQc=; b=B2DdNleSRTzyvzmjmSCjywhrVdX+DPI1Vp3EpwVALG+3MpZHGM8cJboT0N6iqkjH/L XAifDxWyZNn0cqRXEaTxOn8K9y8s0/ZvoG4OoAIZ+1NBrsT8zmrH8uYiLaNvf1gSdUiz iWYm7Jy9xlx/PTTX8KLb2U3fghj7UsqXIwBKNaYKBbSpErManKF8zpEobCzoffHqi7IB /Q/qPPffkJLkB1GdYL/RKimIdEk9B45NlQWIp33H2DsUHEnt9CLcmZFNTFJaYXcFgd+A 4hXsJziXxu7C9PAwYWSD0QV3JZh67N8JTN3ioemQfe7QrwOT6cLIhuMs4qyAs6zz5YnD AhHg== X-Gm-Message-State: AOJu0YxqPYAohSI/HvqindN8JR44RXqWRXOqoSEdilpQSRm88dyiU/3V xQkRXb2f6/abcobee3XZVkTmn9mx+d7S6X/u2WWZf7WEOPVdl2l9bERU/EHITelaCJDaWxvYlli j/q8sGc23EurTVuqPNM2MWpnJe+M0DtY4KNSg X-Gm-Gg: Acq92OFURBE0JSLyqYNsllJ18Rb77s21rnbWz0rLHTS7iP5uA+qWTo3+0yYeZIAlWCI VuCOhmq5ae6Xjf5VWN+ZOrXLh6R6pMPDYL7KyY+ENtsqwC0kIqtB+LBoYfvDZpMUc0B0h5bXwFX 6CqReHYZCAQx9wwnxZ+I0qMgx+32uKwYt6ZS9JWhdMzvCCUFpv/6931WEv8p8mhop/kFnTUJNN+ 3vai4KVKrYliTTm+2cek16DTjQPwffRWWExRzQm5fUdmv9KhF72MMXIlaxwNW/zaczFfYxhRKg/ TuItyWgdiwuhULQy2H2OJOA2m85lx+nWANwr1YmkQn4Ghck7 X-Received: by 2002:a2e:a908:0:b0:396:2845:570d with SMTP id 38308e7fff4ca-396284557fbmr29960731fa.6.1779981568160; Thu, 28 May 2026 08:19:28 -0700 (PDT) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol> In-Reply-To: <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol> Date: Thu, 28 May 2026 11:19:16 -0400 X-Gm-Features: AVHnY4L6p7-BVvufRBvdEbRsRUXq7q_Z3sU7J4_rVGDqSNpJJJzMJpF46jBSY2g Message-ID: Subject: Re: [PHP-DEV] AW: [Pre-RFC] Pure-code source files via .phpc extension To: PHP internals Content-Type: multipart/alternative; boundary="00000000000013b81c0652e2412a" From: tendoaki@gmail.com (Michael Morris) --00000000000013b81c0652e2412a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2026 at 8:13=E2=80=AFAM 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 feedback before drafting. > > Proposal in brief: > > Files ending in .phpc would be parsed starting in ST_IN_SCRIPTING state. > No 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 (C= LI > 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 tokens inside > .phpc files. I will also coordinate with Composer maintainers ahead of RF= C > 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? M= y > intent is yes. > > I welcome substantive critique. If the concept itself is unwanted, I woul= d > rather know now than discover it during a vote. > > Thanks. > > Hendrik Mennen > Maintainer, PHPolygon > > I've proposed things very similar to this before, so these are my thoughts and points raised earlier. 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. 2. IDE's will have to be updated for these files as they parse PHP based on the presence of the tags? 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. --00000000000013b81c0652e2412a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 27,= 2026 at 8:13=E2=80=AFAM hmennen90@g= mail.com <hmennen90@gmail.com= > wrote:
=
Hi internals,

I intend to submit an RFC introducing a new file extension for pu= re-code PHP source files (no leading <?php required) and would like to g= ather feedback before drafting.

Proposal in brief:
=
Files ending in .phpc would be parsed starting i= n ST_IN_SCRIPTING state. No <?php or ?> tags permitted inside such fi= les. Existing .php files and their semantics are completely unchanged. This= is purely additive and BC-clean.

<= /div>
Motivation:

<= /div>
PHP's mixed-mode default reflects its 1995 templa= ting origins. Since PHP 7+, the language has evolved into a credible genera= l-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 thi= s pattern. A dedicated pure-code file format would be a small but meaningfu= l acknowledgment that PHP-as-language is now a first-class use case alongsi= de PHP-as-template.

Prior art and what's different:

I have read both rfc/source_files_without_o= pening_tag (Boutell, 2012, abandoned by author) and rfc/nophptags (Ohgaki, = 2014, inactive). My proposal deliberately avoids what I believe were the tw= o design choices that killed them:

=
- No new include syntax (Boutell's AS keyword). = Extension-based detection only.
- No php.ini-based mo= de 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 i= n zend_compile_file, lexer state initialization, OPcache awareness, CLI sup= port, and rejection of <?php/?> tokens inside .phpc files. I will als= o coordinate with Composer maintainers ahead of RFC submission to confirm a= utoload support.

Open questions for the list:
1. Is the .phpc extension acceptable as the disambi= guator, 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 pe= rmitted before the implicit scripting state begins? My intent is yes for bo= th.
3. Should __halt_compiler() retain its current be= havior 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


I've propo= sed things very similar to this before, so these are my thoughts and points= raised earlier.

1. Extension based parsing isn= 9;t a popular idea. The first few responses to this have echoed this, but t= here's a certain power in allowing the parser to not care about the ext= ension.
2. IDE's will have to be updated for these files as t= hey parse PHP based on the presence of the <?php tag being detected.

3. My suggestions have been to use a special require = statement to pull these files in - require_module, require_library. This ge= ts around the problem of the extension mattering. The rule could be set tha= t these files are always include only once. However, this introduces a new = problem - composer will need to somehow know which require technique to use= if there's more than one to choose from.

4. P= HP has several braceless syntax control structure commands - Would these st= ay around or should they too go away since they aren't really needed in= a code first file.

5. The ability to avoid an acc= idental echo and therefore mess up headers is pretty valuable, but what els= e is going to be picked up? Can the token parser iterate over the file fast= er if it doesn't have to look for <?php ?> tags?

6. I would caution against any code only include being implemented= without taking the opportunity to fix certain bugs that have gotten to sti= ck 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=C2=A0to clean some things that should not= be passed on. Please, Please look into this as part of this.=C2=A0
--00000000000013b81c0652e2412a--