Re: [RFC] Pure-code source files via the .phpc extension

> Am 16.06.2026 um 09:26 schrieb Davey Shafik <me@daveyshafik.com>: > >> On Jun 15, 2026, at 21:25, Hendrik Mennen <hmennen90@gmail.com> wrote: >> > <snip> >> >> If that friction is not worth solving, that is a legitimate position >> and I would rather hear that than dress the proposal up to look >> weightier than it is. Three honest paths from here, and I would find >> it useful if respondents could say which they are closest to: >> >> 1. The friction is real and a small targeted addition is worth >> shipping. (what the RFC proposes) >> 2. The friction is real but the mechanism is wrong. (in which case: >> what signal would you prefer? per-file declare, magic first line, >> SAPI-only, ...) >> 3. The friction is not real, or not worth a language change at all. > > I am strongly in camp 3; I see zero value in this. > > Adding meaning to a specific extension is a BC break when no extensions have meaning prior. In > addition, it makes it difficult to identify the file type from the code alone if you're not > familiar with it. > > There really isn't any friction here, any decent editor or IDE will give you a default > file header with the open tag (at least). At worst they'll auto-complete after at most 2 > characters. > > It's also important to note that other languages have explicit template files like Jinja > or ERB, PHP does not have this and is itself essentially both the template language and the full > programming language. > > Yes it's a legacy way of doing things like ASP classic or ColdFusion, but that > doesn't make it wrong or bad. > > - Davey Hi Davey, Thanks for the direct camp-3 position - the (1/2/3) framing was intended exactly to surface that kind of clarity, and a voter landing explicitly in 3 with substantive reasons is more useful to me than vague reservations would have been. I won't try to argue you out of camp 3 - your stance is well-formed and arguing past it would just escalate. A few responses point-by-point, primarily for other readers who are still forming a view. > Adding meaning to a specific extension is a BC break when no > extensions have meaning prior. Mostly conceded, with one nuance: .phar already carries filename-aware semantics in the engine (the phar:// stream wrapper resolves entries against the .phar filename, and the archive opens differently from a regular file). It is not a clean precedent for "extension drives lexer mode at file-open time", but PHP does not have //zero// precedent for filenames mattering to the engine. You are right that this RFC would be the first to make filename drive lexer state. That is a categorical shift even if no existing code's behaviour changes. The RFC was leaning too hard on "strictly additive" framing; I have added an explicit "this is a categorical precedent shift" entry to the "What this RFC does NOT claim" section in v0.4 (just published, see Changelog). > It makes it difficult to identify the file type from the code > alone if you're not familiar with it. Conceded as a real cost. The <?php opener is a portable "this is PHP" marker that travels with code into Stack Overflow answers, blog posts, diff views, IDEs that hide extensions. A naked .phpc snippet loses that signal until the reader has learned what .phpc means. Also added as an explicit downside in the v0.4 "does NOT claim" section. The flip side (most snippets already drop <?php in practice because the surrounding context is clear) softens the cost but does not erase it. Reasonable to weigh it at "small but real". > There really isn't any friction here, any decent editor or IDE > will give you a default file header with the open tag Agreed; the typing cost is microscopic. The RFC has tried to say this honestly ("not a big ergonomic win" was already in the Motivation section). What remains is the //read// cost: the visual noise of <?php on every file you open. You can reasonably value that at zero, especially if your IDE renders the opener in a muted colour or folds it. > Other languages have explicit template files like Jinja or > ERB, PHP does not have this and is itself essentially both the > template language and the full programming language. [...] Yes > it's a legacy way of doing things like ASP classic or > ColdFusion, but that doesn't make it wrong or bad. Agreed - PHP's template-and-programming-language duality is a real and ongoing identity, defended even by people who never write inline templates themselves. .phpc does not change that: .php files continue to support full templating, mixed mode, short tags, ?>, the lot. .phpc is an opt-in for files where the author has decided "this is code, no template behaviour wanted". On the legacy framing: those languages died for many reasons, but "you could use them as a template engine" was not one. PHP's longevity is partly because of that duality, not in spite of it. I would not pitch .phpc as "removing the legacy" - it is purely adding a way for individual files to opt out of inheriting it. --- If you have time, one clarifying question that would help shape the rest of the discussion: Is your camp-3 stance disqualifying the specific mechanism (.phpc-extension dispatch), or disqualifying the broader concept of "let me write a PHP file without <?php" regardless of mechanism? Camp 3 on the mechanism is actionable for future iteration; camp 3 on the concept is information that tells me to stop spending the Discussion's air time on this. Either answer is useful to know. Regards, Hendrik