Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:131037 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 004E51A00BC for ; Thu, 28 May 2026 15:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1779982540; bh=6ZjyzvCM2k9lohYo2937yILyL0lzbRv4FQQB1IzphT8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=A+jESuv4hhs0u1W65r2dNGT31AsuHMMFe6Ae8t5YfDKA7TmOHyeXxOuzRVDc5RN7S ZB7TM2OPoJ/rOeOI7huxkIPGw2bksbjfO4Uf9T1rMQBc0M1Z9PkCuDtFUu1jsfVD08 gddtxc7zTL9GlAw0vGoesmXiYC9tH8a/x9u+v0A9tHwGDasSSvsdpsj4lwODSBHpRM vOJd7jQXDjCBPQXuWo+9FUfLTd6NGKaj7iwGAJvUE4RaYRuhXAR+TFAX+DNtqhf6Tk AAW6mwe9NhjgA6vVW5DaroemHaq54UAgpUP0PSSIeQjOlKjDjATOcrepeJ5KBTRTwx mlN902WTVRuNg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E7D43180506 for ; Thu, 28 May 2026 15:35: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=0.9 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,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-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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:35:38 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-45ee6d32402so470504f8f.1 for ; Thu, 28 May 2026 08:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779982532; x=1780587332; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=k06jTbpDPIe0K+OSd8FlPzs34MD7r/WsqgP7TTkcQpM=; b=HbUiAAlD/7r4xlqk15NIzBn2F1+zDyS6R4KDjNJERjVyjvtnfIB4nKLGWNVTyPT0d2 RHMyOUyX8S8r+YVcctm/ANn8Kr+Pnx4IoTGUOFtV3GSv4uMJxgoT6d1/JGX13xN6mc7w 4tRGKGLTZBPmalqDLxZ7Yda+acP7v0ETK+m4SOlAYMdWE+h2tOW34fdLeQ+BbM6BMqvq NGgAR6Xj8iETumm8XgQQbFrgqllqQ3UAOEgzZayEeMzOUW+G4NVbseyq8SQtKAq51Wok wpfgcbEYBLverRNm51fyVoT1Dv2NhbMqcXYPHxDuBklBpyDCi4oVatn3OYUb5hXV1ta8 BMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779982532; x=1780587332; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k06jTbpDPIe0K+OSd8FlPzs34MD7r/WsqgP7TTkcQpM=; b=PU4IWtW++O3/R/EGxPAaTrlY86T7T80vSZdI/P2Z77QoA2JMYZgXVrl00487vE0SfJ DcHHKsMOW0qo++5KuDDeLsIlUTcwnoOSLMYuZf3CCSfz/ZA06NMoVi242VHjHhfwBSfp USxVVbuT+kphvNPeO2YI9No8QC93+qUAMUYllN09WfYdZvwgSlzyPgORo8Tuu2Kt1fuZ 2AcGc3pYnDOzlmVpfWKMLVe7els0rhIhmED6CWiS4JmIZTMnKqfw+3T9SvPYWmW/FHgW 4WLvFKlfMc4ONKNf+aXu7lNHNq8DnyOgoKDFPFJ+xh+x6Bw0XXn6/yRYJetNnK3OaZ8z xo6w== X-Gm-Message-State: AOJu0Yx1ivRaCw7grEY+GMlo0FsSVyssXwQ0zuKbAytONvjL2STscGFI 0rvelJTZwg5iBNoYItASeUaMoXhouQUmRCEzJIcCLQNAJuFgJkTn3Mt7SLtB7wFe X-Gm-Gg: Acq92OFZW1zLSmasiWmKOfL9Xn8ieJ/txwZm846dHTYw7ltT3SOkk7YnWLDLlNWiJ3N ibzSwpNHlKw//pOWxgm1+p4yhY5L4JMW1TBHt5HqUxRlYdyAGTMCfQXIGXfU6Bz34RF3ftGQf4a jScp+ZBcgUKIzUyY/PcgiOFBvPBu/kTkUB8CZRh6SOfDdRB7NP5YU2GfCWybkzQGLWQHXLsAwJ6 mCWvFdlHGlwUj9YH8kCVxLGscztan94q5pXhCZnO6XndkuJa7byfIpcLlYy8GdL8X6KzY/CgO0r 1MrMo3WI9oERn4ubOLJbADOxuk93MNOUo2VvNNNM8OCDkZkhzyfv4c5+LvJLl/sXMiHTFKDwjgm ceY5hl3B4IiCaufHAMq8Tdp9GFL3mtHlcTOD5f0UW27rukLAE1xzYJ4tK+tJML8L6tJR1HlpT1V gKdQ7q7dk4In1ukuvzhbFOANNfQg2iU51ixiPVg/QYqnGAy0AeHf/9Z5X1jw1hJ0ya3Xkf99Mz4 4XT+mrbpLibe6oMcIuPaEDp X-Received: by 2002:a05:6000:26c1:b0:44d:1338:46b4 with SMTP id ffacd0b85a97d-45eb36731d0mr47805926f8f.9.1779982532081; Thu, 28 May 2026 08:35:32 -0700 (PDT) Received: from smtpclient.apple (p508ccfb8.dip0.t-ipconnect.de. [80.140.207.184]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ee5a84e92sm5630753f8f.35.2026.05.28.08.35.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2026 08:35:31 -0700 (PDT) Message-ID: <11B6D9B0-2555-4FC4-B540-71680315589F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_168AADCF-086B-4D9E-AAC8-DB9B2B47BFFD" Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow 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: Thu, 28 May 2026 17:35:19 +0200 In-Reply-To: Cc: PHP internals To: Michael Morris References: <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol> X-Mailer: Apple Mail (2.3864.600.51.1.1) From: hmennen90@gmail.com (Hendrik Mennen) --Apple-Mail=_168AADCF-086B-4D9E-AAC8-DB9B2B47BFFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 28.05.2026 um 17:19 schrieb Michael Morris : >=20 >=20 >=20 > On Wed, May 27, 2026 at 8:13=E2=80=AFAM hmennen90@gmail.com = > wrote: >> Hi internals, >>=20 >> I intend to submit an RFC introducing a new file extension for = pure-code PHP source files (no leading >=20 >> Proposal in brief: >>=20 >> 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. >>=20 >> Motivation: >>=20 >> 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. >>=20 >> Prior art and what's different: >>=20 >> 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: >>=20 >> - 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. >>=20 >> Implementation: >>=20 >> 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 = RFC submission to confirm autoload support. >>=20 >> Open questions for the list: >>=20 >> 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. >>=20 >> I welcome substantive critique. If the concept itself is unwanted, I = would rather know now than discover it during a vote. >>=20 >> Thanks. >>=20 >> Hendrik Mennen >> Maintainer, PHPolygon >>=20 >=20 > I've proposed things very similar to this before, so these are my = thoughts and points raised earlier. >=20 > 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 =20 > 3. My suggestions have been to use a special require statement to pull = these files in - require_module, require_library. This gets around the = problem of the extension mattering. The rule could be set that 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. >=20 > 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. >=20 > 5. The ability to avoid an accidental echo and therefore mess up = headers is pretty valuable, but what else is going to be picked up? Can = the token parser iterate over the file faster if it doesn't have to look = for tags? >=20 > 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.=20= Hi Michael, Thanks, this is the densest critique so far and worth working through = point by point. I am also aware that this topic overlaps significantly = with the Modules direction you have been iterating on over the past = couple of years, so some of these answers will inevitably touch on that = prior work. > 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. 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. > 2. IDE's will have to be updated for these files as they parse PHP > based on the presence of the 3. My suggestions have been to use a special require statement to pull > these files in - require_module, require_library. [...] 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. This lines up with your Modules iterations, and is in the same family as = Alex's include_pure and Tom Boutell's 2012 require AS INCLUDE_PURE_CODE. = I have two reservations about it as the primary mechanism, and you have = actually surfaced the second yourself: - The parsing context lives with the caller, not the author. A library = author cannot guarantee their files will be loaded the right way, = because consumers might use the wrong require. - The Composer autoload problem you describe. If there are multiple = require variants, the autoloader has to pick one. The only way around = that is per-file metadata that tells the autoloader which to use, which = is exactly the kind of out-of-band signaling that extension dispatch = avoids. 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. > 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. Good question, and I think this deserves explicit discussion in the RFC. = The alternative syntax (if: endif;, foreach: endforeach;, etc.) exists = primarily because it reads better in templating contexts where you have = ...HTML.... In pure code, you would = always use braces. Two reasonable positions: (a) Allow it for consistency with .php files. Linters and code style = tools can flag it as inappropriate in pure-code files without the engine = treating it as an error. (b) Disallow it. The new file format has the freedom to be stricter, and = the alternative syntax serves no purpose without templating. My current preference is (a) for minimum surprise, but I would not fight = hard against (b) if there is appetite on the list. This is exactly the = kind of question I want to surface in the RFC text rather than decide = unilaterally. > 5. The ability to avoid an accidental echo and therefore mess up > headers is pretty valuable, but what else is going to be picked up? > Can the token parser iterate over the file faster if it doesn't > have to look for tags? On parse speed: marginally yes, but in practice the difference is = invisible. OPcache caches the opcodes after the first parse, so for any = non-cold-start request the lexer mode-switch is not in the hot path. JIT = does not change this picture either, since the inline-HTML T_ECHO = opcodes that mixed-mode files produce are not what JIT optimizes anyway. 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. "What else is going to be picked up" - this connects directly to your = point 6, which I think deserves its own treatment. > 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-decade 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 = format 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 = focused 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 variable variables, banning @ error suppression, banning the = global keyword. But I would value your concrete examples more than my = abstract candidates. Thanks again for the substantive engagement. Hendrik Mennen Maintainer, PHPolygon= --Apple-Mail=_168AADCF-086B-4D9E-AAC8-DB9B2B47BFFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Am 28.05.2026 um 17:19 schrieb Michael Morris = <tendoaki@gmail.com>:



On Wed, May = 27, 2026 at 8:13=E2=80=AFAM hmennen90@gmail.com <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


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 <?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 gets around the problem of the extension = mattering. The rule could be set that 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. 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.

5. The ability to avoid an accidental = echo and therefore mess up headers is pretty valuable, but what else is = going to be picked up? Can the token parser iterate over the file faster = 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 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. 

Hi = Michael,

Thanks, this is the densest critique = so far and worth working through point by point. I am also aware that = this topic overlaps significantly with the Modules direction you have = been iterating on over the past couple of years, so some of these = answers will inevitably touch on that prior = work.

> 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. 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.

> 2. IDE's will have to be = updated for these files as they parse PHP
>   =  based on the presence of the <?php tag being = detected.

True, and the same is true for static = analyzers (PHPStan, Psalm), the nikic/php-parser library that most of = those depend on, and Composer's autoloader. I have on my list to talk to = the Composer maintainers ahead of the formal RFC, and I would extend = that to PhpStorm and the analyzer maintainers. The change for an IDE is = small once the underlying parser library handles the new mode (treat the = file as starting in scripting state). PhpStorm in particular already = handles .phps and other variants, so the lift should be = modest.

> 3. My suggestions have been to use = a special require statement to pull
>    these = files in - require_module, require_library. [...] = 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.

This = lines up with your Modules iterations, and is in the same family as = Alex's include_pure and Tom Boutell's 2012 require AS INCLUDE_PURE_CODE. = I have two reservations about it as the primary mechanism, and you have = actually surfaced the second yourself:

- The = parsing context lives with the caller, not the author. A library author = cannot guarantee their files will be loaded the right way, because = consumers might use the wrong require.
- The Composer autoload = problem you describe. If there are multiple require variants, the = autoloader has to pick one. The only way around that is per-file = metadata that tells the autoloader which to use, which is exactly the = kind of out-of-band signaling that extension dispatch = avoids.

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.

> 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.

Good question, and I think this deserves = explicit discussion in the RFC. The alternative syntax (if: endif;, = foreach: endforeach;, etc.) exists primarily because it reads better in = templating contexts where you have <?php if ($x): = ?>...HTML...<?php endif; ?>. In pure code, you would always use = braces.

Two reasonable = positions:

(a) Allow it for consistency with = .php files. Linters and code style tools can flag it as inappropriate in = pure-code files without the engine treating it as an = error.

(b) Disallow it. The new file format has = the freedom to be stricter, and the alternative syntax serves no purpose = without templating.

My current preference is = (a) for minimum surprise, but I would not fight hard against (b) if = there is appetite on the list. This is exactly the kind of question I = want to surface in the RFC text rather than decide = unilaterally.

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

On parse speed: marginally = yes, but in practice the difference is invisible. OPcache caches the = opcodes after the first parse, so for any non-cold-start request the = lexer mode-switch is not in the hot path. JIT does not change this = picture either, since the inline-HTML T_ECHO opcodes that mixed-mode = files produce are not what JIT optimizes = anyway.

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.

"What else is going to be picked up" - = this connects directly to your point 6, which I think deserves its own = treatment.

> 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-decade = 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 format 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 focused 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 variable = variables, banning @ error suppression, banning the global keyword. But = I would value your concrete examples more than my abstract = candidates.

Thanks again for the substantive = engagement.

Hendrik = Mennen
Maintainer, PHPolygon
= --Apple-Mail=_168AADCF-086B-4D9E-AAC8-DB9B2B47BFFD--