> Am 16.06.2026 um 09:26 schrieb Davey Shafik <[email protected]>:
>
>> On Jun 15, 2026, at 21:25, Hendrik Mennen <[email protected]> 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
