#externals

Spam on PEAR site

Thu, 18 Jun 2026 10:38:38 +0000

On 18 June 2026 07:13:13 BST, Nick Sdot php@nicksdot.dev wrote:

Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam.
You'll have to talk to the pear team for that, as we don't have access.

As a quick and dirty fix can we just deny any requests to the relevant endpoints and spam proposals at the CDN?

It doesn't sit behind a CDN. And I have no access to the server.

I can drop the whole hostname from DNS.

cheers
Derick

Should base_convert raise a notice/warning on precision loss?

Thu, 18 Jun 2026 09:59:47 +0000

Hello,

base_convert converts between numerical bases, such as from decimal to hex. It stores an intermediate result in a double, and thus loses precision for big numbers. This is a problem when used on big numbers in security contexts. This semi-often happens when users want to create a "nice" random token:

$token = base_convert(bin2hex(random_bytes(16)), 16, 36));
// "7nr0r976rl8o4wkwkkkcc84og"

This looks like a nice random string, but converting it back to hex shows that it is actually mostly zero:

var_dump(base_convert("7nr0r976rl8o4wkwkkkcc84og", 36, 16));
// "8161d6d5f47bb0000000000000000000"

Should base_convert raise a notice or warning when it cannot convert a number precisely? On one hand, silent conversion to floating point is just fact of life for PHP. But I would argue that in this case it is unexpected because both the input and output are strings. The loss of precision is documented in the manual, but it is not obvious from the result, and it has clear security impact. What do you think?

Regards,

Sjoerd Langkemper

Spam on PEAR site

Thu, 18 Jun 2026 08:26:01 +0000

On 18 June 2026 07:13:13 BST, Nick Sdot php@nicksdot.dev wrote:

Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam.
You'll have to talk to the pear team for that, as we don't have access.

cheers
Derick

As a quick and dirty fix can we just deny any requests to the relevant endpoints and spam proposals at the CDN?

Davey

Spam on PEAR site

Thu, 18 Jun 2026 08:05:58 +0000

Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam.
You'll have to talk to the pear team for that, as we don't have access.

cheers
Derick

[RFC] Case sensitive PHP

Thu, 18 Jun 2026 07:58:35 +0000

I think this is a good idea, however I think some care needs to be
taken so that it doesn't impose a significant burden on end users
compared to the benefit returned.

In respect to the exact detail:

2.9: As already noted by Juris, I also disagree with changing
::class resolution to have magic behaviour based on if the class
exists or not (at the time of the usage) - I would prefer keeping that
as a static transformation and raising the deprecation if the string
is used.
2.37: The example is a little unclear; could the example be updated
to include the actual class instantiation / function call; and confirm
if the error message references the line of the call site / the line
of the use statement / both? Further to this, just to confirm it is
correct; there is no difference in the error message when a use
statement is/isn't present?
2:37: When I read 'The as alias itself is not checked: use
MyApp\Service\UserService as US is fine regardless of what US is. Only
the namespace path being imported is validated.' then I interpreted
that as it would mean that in the code the developer could do new us(); - is that correct? If not, it might be worth just reviewing the
wording.
2.39 / 2.40: I don't agree with this in the initial version - it
makes sense to do but I would prefer this as a future change.
Initially I would suggest that unserialize continues to work without a
deprecation / error - the update that a developer would need to do in
response to the deprecation occurring (for data still serialized)
would either be having a script that unserializes and then
reserializes the data just to correct the case, manual editing the
data, or ignoring/suppression the deprecation; none of which seem
particularly useful against the harm by having a special case when
unserialzing data. (Note this relies on prohibiting multiple items
with the same name but different case for a period from my general
feedback)
2.41: My SOAP knowledge is a bit rusty; but from memory then naming
on the SOAP side are case sensitive; but if I am incorrect here then I
would not enforce case sensitivity on the PHP side either (as the
types could change on the server side with no ill effect)

General:

What change is there to the default implementation for __autoload
(https://www.php.net/manual/en/function.spl-autoload.php)? Currently
this will load class names with any case as long as the PHP files are
lowercase in the file system (or a case insensitive file system is
used).
Would a function that can normalize the case of items currently case
insensitive be useful to introduce alongside this (where the item
exists in the symbol tables of course)? My thoughts are for
compatibility with code you don't control - if a third party library
intends to change their internal casing following this change; a
developer may want to be able to use a proxy for accessing their
resources that allows the old casing to work without raising the
deprecations (or errors in PHP9) once the update is released without
needing to immediate update the first party code. (This could be done
in userland, but I would expect it would be more efficient to do in
the engine)
For some internal classes/functions which don't follow the expected
rules, should aliases be introduced (or the deprecations suppressed
during the deprecation stage). Although I rarely use it myself, I only
realised when reviewing this RFC that 'stdClass' is not 'StdClass' for
instance.
I would suggest that for PHP9.0 then having multiple items (or at a
minimum then autoloadable items) with the same name but with different
casing is prohibited. I would be concerned of much harder to detect
issues if PHP8.6 introduces the deprecation and then PHP9.0 (assuming
that was the next release after 8.6) then removed the deprecation and
allowed you to define the classes 'Foo' and 'foo' that a significant
number of users would upgrade from PHP8.5 to PHP9.0 and manage to end
up with different items that they expect are the same. I wouldn't have
an issue allowing it in PHP10; or given the motivations given so far
for the change keeping this prohibted.

Robert

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I have collected the points raised in previous discussions, and browsed all affected language features and functionalities.

I still need to perform the impact analysis and the performance benchmarks. I will add them to the RFC and inform in the thread when I complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

[RFC] Case sensitive PHP

Thu, 18 Jun 2026 06:55:10 +0000

Thanks for all opinions. I will apply all changes in coming days to the RFC
content.

Is there a practical, real-world issue this solves?

Portability of the autoloading. I had a case in the past where my wrongly
cased namespace didn't cause any problem locally, but it failed in the
production because of different OS. This is real world-issue.

However, this problem touches only namespaces and class names. If the RFC
would be only for namespaces and classes would you be in favor of this RFC?
It appeared in previous discussions to put all or nothing into such RFC, so
I went along the lines, but I'm okay with dropping methods and functions.
However, if RFC function autoloading would pass, we would have the same
problem with functions.

Kind regards,
Jorg

Spam on PEAR site

Thu, 18 Jun 2026 06:13:13 +0000

Hey all,

I already mentioned this a few month ago in the "Deprecate PEAR and
recommend Composer" RFC discussion.
The discussion died down, no one picked up on it, and the RFC seems
stale for now.

Hence, re-sending it this as a new topic for visibility:

On the PEAR website, the proposals with the IDs 710, 711, 708, 83, 662,
700 contain online casino links (and/or other spam).
Some of the proposals have the same account as last editor in their
changelog -- perhaps the account was hacked.

The last real proposal was in 2013. The newest three proposals sole
purpose seems to get links in. For instance, 710 is an exact copy of 83
from 21 years ago.

Perhaps it would make sense to disable editing old and adding new
proposals, and remove the spam.

Cheers
Nick

[RFC] Separation of Third-Party Extension Documentation

Thu, 18 Jun 2026 05:42:08 +0000

Hello,

I've opened an RFC to separate third-party extension documentation
(imagick, redis, mongodb, etc) from the official PHP manual, while
keeping the existing DocBook tooling and infrastructure.

Bundled extensions (pdo, curl, etc) are out of scope and stay in the
official PHP manual.

https://wiki.php.net/rfc/third_party_ext_documentation

Hey Jordi,

thanks for the RFC, I am all for this!

From the RFC:


Third-party extension documentation will be hosted in a single monorepo, 
mirroring the structure of the existing|doc-en|repository. Each 
extension occupies its own subdirectory, and the repository uses the 
same DocBook-based tooling as the official manual.

Commit access may be granted to extension maintainers in addition to the 
PHP documentation team. Pull requests remain open to anyone, as 
with|doc-en|.

How about co-locating the documentations in the extension repositories?
Tooling could pull in the documentations from there.

Moving third-party docs to a monorepo sounds like it moves parts of the
maintenance burden and confusion from place A to place B under the same
roof.
The responsibility to manage access still would be with the docs team.
Third party docs still would live in a phpc owned repository.

Benefits of co-locating:

docs fully owned by extension
no access management burden for docs team
no bad look for phpc if the monorepo has hundreds of open issues/prs
(if some maintainers don't care)
maintainers can document as they go; doc changes can land in the same
pr/commit
maintainers can choose their own workflows, issue templates, etc.
users can contribute where the extension lives; maintainers directly
handle contributions
maintainers triage/handle only their own issues/prs in their own repo,
without being overwhelmed by unrelated issues/prs
no confusion about why third-party docs live in official PHP repos
archiving/removing docs is as easy as removing/deactivating the
external integration source

I think co-locating would add a lot of value, while still achieving the
goal you propose.

Admittedly, this approach would require slightly more coordination than
your proposal. It, however, would also serve as a great first filter to
evaluate which extensions are still maintained, hence worth documenting
(promoting), and which not. The initial move could be automated with PRs
to the extension repos. I'd argue the extra effort is negligible and the
upsides outweigh it.

Thoughts?

Cheers
Nick

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

Thu, 18 Jun 2026 03:12:17 +0000

It would at least solve the problem of accidental output prior to
the opening tag, though I'm not sure how big of a problem that really
is.
I'm not sure it would even solve the problem. It's surely very easy to
spot bogus output when the opening <?php is missed in a pure-code file
(even before the file is saved if the editor is highlighting syntax).
There is a much better chance of missing the tag in the middle of a
template file - perhaps on a code path that isn't always taken - down
where a lot of similar punctuation is already happening.

[RFC] Working Groups

Thu, 18 Jun 2026 03:07:11 +0000

I'm opening discussion on an RFC to create a policy for PHP project
working groups:

https://wiki.php.net/rfc/working_groups

I've made substantial changes to the Working Groups policy RFC that I'd
like to call your attention to.

I've moved the full text of the policy out of the RFC, replacing it with
a simplified introduction and link to the policy pull request:
https://github.com/php/policies/pull/35

Additionally, I've made the following changes to the policy text:

clarified that approved charters grant autonomy to operate
within the scope of the charter without separate RFCs
added a section on PHP Project resources (VCS repositories,
mailing lists)
specified that working group policies should be documented
in the working group's repository rather than enumerated in
its charter

For more details, see the full diff here:
https://github.com/php/policies/pull/35/changes/3d2d111504327a50fa7cddec54d021aff00c3063

Cheers,
Ben

[RFC] Case sensitive PHP

Thu, 18 Jun 2026 02:35:59 +0000

Is there a practical, real-world issue this solves? I have never in my life seen someone write STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if they've ever changed that and it doesn't hurt anything. Class names everyone should already be treating as case sensitive because of the file system. And IDEs and SA tools have been pushing toward the "standard" casing of things for decades. I don't really see this as an issue to solve.

I think end users see no problem being solved here. And that's okay.
However, this change helps the engine (and any tool that deals with
PHP symbol definitions, analyzers, LSPs, etc.) by making symbol
management easier, as it removes the need for a folding pass required
on every identifier encountered.

This also helps make PHP more consistent, first, with other
programming languages, and secondly, with itself, since constants in
PHP are already case-sensitive, so making everything behave the same
is a win.

And as you said, no one writes STRLEN, and people write code
assuming that the casing they are using is correct per definition, not
for style reasons. The deprecation phase would help people spot
incorrect casings in their application for now, until the 9.0 upgrade.

Cheers,
Seifeddine.

Primary Constructors

Wed, 17 Jun 2026 21:44:02 +0000

Hello internals,

I was reminded of my records RFC today, and one of the features of the RFC was "short constructors" generally called "primary constructors" in C#/Kotlin.

They would look like this:

class Point(public int $x, int $id = 0) extends Base($id);

Which is just sugar for this:

class Point extends Base {
public function __construct(public int $x, int $id = 0) {
parent::__construct($id);
}
}

or this:

class Point extends Base {
public int $x;
public function __construct(int $x, int $id = 0) {
$this->x = $x;
parent::__construct($id);
}
}

A class with a primary constructor may not have a defined __construct function. Any special initialization must be done with hooks:

class Temperature(
public float $celsius {
set {
if ($value < -273.15) {
throw new ValueError('below absolute zero');
}
$this->celsius = $value;
}
}
) {}

new Temperature(20.0); // ok
new Temperature(-300.0); // ValueError: below absolute zero

I'm sending this email to the list to gather additional feedback before pursuing a formal RFC proposal.

— Rob

I just realized that my examples did not demonstrate the classes with a body, but they may also have a body!

— Rob

Primary Constructors

Wed, 17 Jun 2026 21:32:05 +0000

Hello internals,

I was reminded of my records RFC today, and one of the features of the RFC was "short constructors" generally called "primary constructors" in C#/Kotlin.

They would look like this:

class Point(public int $x, int $id = 0) extends Base($id);

Which is just sugar for this:

class Point extends Base {
public function __construct(public int $x, int $id = 0) {
parent::__construct($id);
}
}

or this:

class Point extends Base {
public int $x;
public function __construct(int $x, int $id = 0) {
$this->x = $x;
parent::__construct($id);
}
}

A class with a primary constructor may not have a defined __construct function. Any special initialization must be done with hooks:

class Temperature(
public float $celsius {
set {
if ($value < -273.15) {
throw new ValueError('below absolute zero');
}
$this->celsius = $value;
}
}
) {}

new Temperature(20.0); // ok
new Temperature(-300.0); // ValueError: below absolute zero

I'm sending this email to the list to gather additional feedback before pursuing a formal RFC proposal.

— Rob

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 20:10:21 +0000

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed
all affected language features and functionalities.

I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

Is there a practical, real-world issue this solves? I have never in my life seen someone write STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if they've ever changed that and it doesn't hurt anything. Class names everyone should already be treating as case sensitive because of the file system. And IDEs and SA tools have been pushing toward the "standard" casing of things for decades. I don't really see this as an issue to solve.

But I can see where it could cause issues when making dynamic method calls, like $controller->$httpMethod($request), which is something a number of smaller frameworks have done for years.

So I'm -1 at this point.

--Larry Garfield

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 15:10:03 +0000

As for the existing stuff that you mention, we already have this casing
salad anyway even if we simply follow IDE autocomplete

Yes we do, hence why I would love for this RFC to pass and the standard
library be unified by the standards you linked.
However, unless compromise is made to do so this RFC would cause more
problems than it solves.

I think this is really down to a case where PHP has held onto too much
legacy problems, and attempts to fix those problems cause more problems.

For userland definitions I think this can be adapted quickly to that
subsection, because ideally developers should be following the
documentation.
It doesn't break PHP, it breaks incorrect implementations of userland
code and helps enforce good developer behaviour, such as following the
definition
Eg, if the developer defines \Movies\ILike\Moneyball and then the
implementer uses \movies\ilike\MoneyBall` then I can agree, that should
generate an error
Implementations like this: https://3v4l.org/FQKLq I 100% agree, should not
be possible.

But for internal PHP definitions I'm not sure what a solution would be
which does not completely havoc.

[RFC] Function Autoloading (mark 5)

Wed, 17 Jun 2026 14:47:22 +0000

Imagine we have an old guzzle/psr7 with stream_for function, and they use it without a qualifier. I defined a global stream_for so now I hijacked the internal library logic. Is it correct?

The previous attempt with namespace pinning made more sense to me

The concern that occurred to me is similar: if I rely on function autoloading, but forget to fully-qualify a name in the current namespace, it would accidentally work as long as some other code triggered loading of that function first. Then some small refactoring - or even a different path through the code at runtime - and it will silently fall back to a function in the global namespace instead.

I think if autoloading is going to require some extra "ceremony" in the code, it would be preferable to have a declare() at the top of the file forcing the interpretation of all unqualified names (either "always assume current namespace" or "always assume global namespace"). That way, code would not change behaviour based on hard-to-predict side effects elsewhere.

Rowan Tommins
[IMSoP]

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 14:21:31 +0000

1. I don't think it's necessary to mess with ::class here.
People are used to it not doing any checks. If it started doing some
checks it would
get confusing: why does it tell me if the case is wrong but says nothing
if the class
doesn't exist? And the warning is fired conditionally on whether the
class is already
loaded or not, which, according to RFC, is not a cool behaviour.

Besides that wrong case warning would disappear and go back to silent
in PHP 9.0, right?
I agree, that #2.9.2 is basically a string constant not really related
to the class itself, adding a check is not beneficial. If that string is
used to initiate a class, there will be some another warning from this
RFC about it anyway.

--
Anton

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 13:59:15 +0000

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed
all affected language features and functionalities.

I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

Hey,

I don't think it's necessary to mess with ::class here.
People are used to it not doing any checks. If it started doing some
checks it would
get confusing: why does it tell me if the case is wrong but says nothing
if the class
doesn't exist? And the warning is fired conditionally on whether the
class is already
loaded or not, which, according to RFC, is not a cool behaviour.

Besides that wrong case warning would disappear and go back to silent
in PHP 9.0, right?

Is the end goal in PHP 9.0 such that ActivityLog and Activitylog
could both be defined
as separate classes? And I can define my own StdClass? Or would
definitions that only
differ by case still be separate?

BR,
Juris

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

Wed, 17 Jun 2026 12:53:35 +0000

Am 2026-06-16 21:33, schrieb Hendrik Mennen:

Reason for this: I’m native German and it’s easier for me to write an
answer with LLM instead of using google translator for words, which
don’t come to my mind.

The majority of participants on this list are not native speakers of
English. Personally I'm a native German as well. Minor grammar mistakes
or a sub-optimal choice of words is not a problem and something that
readers will just autocorrect. If there really is an issue with
something being completely incomprehensible, someone will ask a
clarifying question and usually rephrasing things will keep things
moving. I'd even say that simple language is preferable, because it
increases the chances that folks with varying English skills will be
able to understand what is being said.

LLMs are great at generating incredibly complex sentences with words
that sound smart, but that will make it harder for others, particularly
non-native speakers, to understand things without resorting to tooling
themselves.

If you are really struggling with expressing yourself in English, I
strongly suggest to write the texts in German and translate them to
English. Or write them in English and ask a tool to just correct the
grammar. From my experience DeepL is working well even for technical
texts. This will ensure the resulting message matches the tone and style
of how you would communicate.

All that said, the RFC text itself also appears to come straight from an
LLM. Notably is doesn't follow the RFC template at
https://wiki.php.net/rfc/template and the expected structure from an
RFC. Some important parts are missing. While following the template is
not strictly necessary, it is carefully designed to make sure to guide
authors through the process and make sure they don't forget anything. I
would strongly urge everyone to follow the template, unless they are an
experienced RFC author and have good reasons to diverge.

Specifically missing from your RFC is the “To the Ecosystem” section
from the “RFC Impact”. The voting widgets should also be set up right
from the start so that there is no ambiguity with how the vote will
look.

With regard to the contents of the RFC: The RFC should primarily contain
a factual description of the user-facing behavior of the proposal. The
value for a strong proposal should become obvious by itself.

If it is necessary to specifically argue against “counter-arguments”
within the RFC itself, it is likely that the proposal itself is not
sufficiently strong by itself. Specifically paraphrasing individual
counter-arguments from the discussion within the RFC and then “replying”
to the individual in question is not appropriate for the RFC text,
especially since this easily results in a biased representation by
accident. Discussing the merit of the RFC is what the discussion is for
and to make it easy for folks to find the discussion the reason why the
RFC policy mandates including a link to the discussion thread in the
archives (the link to this discussion is missing from the RFC, only the
pre-RFC discussion is linked).

Similarly, including implementation details within the RFC text is
typically not useful, because the implementation is likely to change
during review and literally is an implementation detail. What is
relevant is how the proposal affects users of PHP.

As for the proposal itself: I don't see value in trading <?php against
an additional c in the filename. And I also don't see writing <?php
as an issue at all. This discussion and the pre-RFC discussion probably
already spent more time than allowing to omit <?php will ever save.

If you want to proceed with the RFC, you should make sure to rework the
RFC to make sure it includes all the important parts from the RFC
template.

Best regards
Tim Düsterhus

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

Wed, 17 Jun 2026 12:18:46 +0000

Am 2026-06-17 01:02, schrieb Sarina Corrigan:

opening tag, though I'm not sure how big of a problem that really is.
Could
we expect any performance benefits from not having to parse for any
closing
tags? I imagine it would be minuscule if anything

I wouldn't be surprised if that would even be a negative performance
improvement, because it's more “conditions” that the parser needs to
keep track of.

But this is all a purely academic discussion: The file is supposed to
sit in OPcache anyways and not be reparsed and recompiled all the time.

Best regards
Tim Düsterhus

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 10:55:59 +0000

I would be fully in favour of this RFC, but there is 1 hurdle which cant be ignored.

What should the PHP naming convention be for these?

Without deciding on what it should be we would be creating a new issue of mix-mash of uppercase, lowercase and camelcase classes for example

Few examples

DateTime is documented as Camelcase - https://www.php.net/manual/en/class.datetime.php

PDO is documented as uppercase - https://www.php.net/manual/en/class.pdo.php

mysqli is documentated as lowercase - https://www.php.net/manual/en/set.mysqlinfo.php

ArrayAccess is documented as camelcase - https://www.php.net/manual/en/class.arrayaccess.php

PHP mixing case of definitions, at least with current system, users can choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache for devs, as they need to remember what different casing each different builtin class is.
It will become a the new ($haystack, $needle) - ($needle, $haystack) problem, and won't gain love from the community.

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I have collected the points raised in previous discussions, and browsed all affected language features and functionalities.
I still need to perform the impact analysis and the performance benchmarks. I will add them to the RFC and inform in the thread when I complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg

I honestly can’t think of anything good that this RFC would bring. It would bring this cased salad into every code base and require changing code if you use a consistent casing throughout your code base. Just so that person and Person are different? That just sounds confusing to me.

I’m not sure the gain — which I’m also unsure what the gain even is — is worth it.

— Rob

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 10:47:02 +0000

I would be fully in favour of this RFC, but there is 1 hurdle which cant
be ignored.

What should the PHP naming convention be for these?

Without deciding on what it should be we would be creating a new issue
of mix-mash of uppercase, lowercase and camelcase classes for example

Few examples

DateTime is documented as Camelcase - https://www.php.net/manual/en/
class.datetime.php https://www.php.net/manual/en/class.datetime.php

PDO is documented as uppercase - https://www.php.net/manual/en/
class.pdo.php https://www.php.net/manual/en/class.pdo.php

mysqli is documentated as lowercase - https://www.php.net/manual/en/
set.mysqlinfo.php https://www.php.net/manual/en/set.mysqlinfo.php

ArrayAccess is documented as camelcase - https://www.php.net/manual/
en/class.arrayaccess.php <https://www.php.net/manual/en/
class.arrayaccess.php>

PHP mixing case of definitions, at least with current system, users can
choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache
for devs, as they need to remember what different casing each different
builtin class is.
It will become a the new ($haystack, $needle) - ($needle, $haystack)
problem, and won't gain love from the community.
There are already policies for that:

https://github.com/php/policies/blob/main/coding-standards-and-naming.rst

As for the existing stuff that you mention, we already have this casing
salad anyway even if we simply follow IDE autocomplete

--
Anton

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 10:30:25 +0000

I would be fully in favour of this RFC, but there is 1 hurdle which cant be
ignored.

What should the PHP naming convention be for these?

Without deciding on what it should be we would be creating a new issue of
mix-mash of uppercase, lowercase and camelcase classes for example

Few examples

DateTime is documented as Camelcase -
https://www.php.net/manual/en/class.datetime.php
PDO is documented as uppercase -
https://www.php.net/manual/en/class.pdo.php
mysqli is documentated as lowercase -
https://www.php.net/manual/en/set.mysqlinfo.php
ArrayAccess is documented as camelcase -
https://www.php.net/manual/en/class.arrayaccess.php

PHP mixing case of definitions, at least with current system, users can
choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache for
devs, as they need to remember what different casing each different builtin
class is.
It will become a the new ($haystack, $needle) - ($needle, $haystack)
problem, and won't gain love from the community.

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.

I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

[RFC] Function Autoloading (mark 5)

Wed, 17 Jun 2026 10:03:07 +0000

Hi all,

This is (by my count) a 5th attempt at adding function autoloading to PHP.

RFC: https://wiki.php.net/rfc/function-autoloading-five-oh

PR: https://github.com/php/php-src/pull/22337

Looking forward to the discussion around this one!

-- pmj

Hi Paul!

To make unqualified calls to strlen() resolve to Foo\strlen() inside the Foo namespace, you must import the fully qualified function first

Imagine we have an old guzzle/psr7 with stream_for function, and they
use it without a qualifier. I defined a global stream_for so now I
hijacked the internal library logic. Is it correct?

The previous attempt with namespace pinning made more sense to me

--
Anton

[RFC] [Discussion] Literal Scalar Types

Wed, 17 Jun 2026 04:59:51 +0000

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

Hi all,

Based on the discussion so far, I've updated the Literal Scalar Types
RFC to v0.2:

https://wiki.php.net/rfc/literal_scalar_types

What changed:

Strict matching is now the proposed default instead of coercion. A
literal type would never coerce, in either typing mode, exactly how
true, false and null already behave: passing 1 where the type is true
is a TypeError even with strict_types disabled. The goal is a single
rule: a type whose identity is one value matches only that value.
The vote is split into three: a 2/3 vote to add int and string
literals, a separate 2/3 vote to add float literals, and a
simple-majority vote for the matching semantics (strict vs coercive).
Float support is now its own, optional question. The RFC discusses
the precision issue in full (0.3 won't match 0.1 + 0.2, because 0.1 +
0.2 === 0.3 is already false today) along with the arguments for and
against, mirroring why floats were left out of enum backing types.
Documented the accepted literal syntax (0x.., 0b.., octal, 4e3,
1_000, and so on) and why named constants, INF and NAN are excluded.
Added RFC Impact notes for extensions and tooling (parsers, IDEs,
formatters, linters, static analysers), plus a Future Scope section
covering array shapes/tuples and integer range types.

Thanks,
Seifeddine.

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

Wed, 17 Jun 2026 04:21:07 +0000

Am 17.06.2026 um 02:58 schrieb Michael Morris tendoaki@gmail.com:

Here's a thought - Instead of .phpc as an extension, why not <?phpc or even <?psf (PHP source file). Explicitly tell the engine "nothing should be before this other than a shebang, no further tags will be in this file.

That also solves the inadverted echo problem and would be fully BC.

Not convinced it would be useful, but it has fewer problems.

I could actually get behind an alternative tag that reads everything as PHP. It would at least solve the problem of accidental output prior to the opening tag, though I'm not sure how big of a problem that really is. Could we expect any performance benefits from not having to parse for any closing tags? I imagine it would be minuscule if anything

Thinking on this a bit more, if it is an independent tag it could hold directives on how the file should be parsed.

<?psf strict ?> Parse the file with strict mode. Here the closing tag means we're done passing directives, no further tags will be allowed in the file and the parser will remain in PHP mode for this file.

<?psf new_scope ?> Create a new scope - that is no variables, symbols or autoloaders will be shared with the file that included this one. This is an alternate way to do containers aside from creating a new function.

Thoughts?

Hm my core idea was, to get PHP a bit more like C#, Python and so on - they also don’t have a start -/ end tags

But as a first goal, your idea seems logical

Hendrik

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

Wed, 17 Jun 2026 00:58:54 +0000

On Tue, Jun 16, 2026 at 7:02 PM Sarina Corrigan sarina.corrigan@gmail.com
wrote:

Here's a thought - Instead of .phpc as an extension, why not <?phpc or
even <?psf (PHP source file). Explicitly tell the engine "nothing should be
before this other than a shebang, no further tags will be in this file.

That also solves the inadverted echo problem and would be fully BC.

Not convinced it would be useful, but it has fewer problems.

I could actually get behind an alternative tag that reads everything as
PHP. It would at least solve the problem of accidental output prior to the
opening tag, though I'm not sure how big of a problem that really is. Could
we expect any performance benefits from not having to parse for any closing
tags? I imagine it would be minuscule if anything

Thinking on this a bit more, if it is an independent tag it could hold
directives on how the file should be parsed.

<?psf strict ?> Parse the file with strict mode. Here the closing tag means
we're done passing directives, no further tags will be allowed in the file
and the parser will remain in PHP mode for this file.

<?psf new_scope ?> Create a new scope - that is no variables, symbols or
autoloaders will be shared with the file that included this one. This is an
alternate way to do containers aside from creating a new function.

Thoughts?

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 00:39:54 +0000

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.

I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

Hi Jorg,

I am in favor of this RFC. Case sensitivity in PHP is particularly
challenging from a static analysis perspective, as it currently requires us
to perform normalization and maintain tracking for both normalized and
original names for error reporting. It is also an issue for Zend itself,
and I see little benefit in maintaining it when the majority of languages
listed in the RFC do not. Existing codebases could resolve these issues
using migration tools, and a deprecation period until 9.0 is a good
approach.

However, I would like some clarification regarding the plan for 9.0 to
"Promote deprecations to E_ERROR." This could be interpreted in two ways:

Replacing E_DEPRECATED with E_ERROR everywhere, which I believe would
be incorrect.
Removing the deprecation and tolower in the engine so that a case
mismatch results in an error as if the symbol does not exist. This seems
like the correct path, but describing it as "promoting deprecations to
E_ERROR" might be misleading. For example, a call like is_a($foo, 'FOO');
that previously emitted E_DEPRECATED and returned true would now return
false.

Cheers,
Seifeddine Gmati

[RFC] Case sensitive PHP

Wed, 17 Jun 2026 00:03:14 +0000

Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.

I still need to perform the impact analysis and the performance benchmarks.
I will add them to the RFC and inform in the thread when I complete it.

RFC: https://wiki.php.net/rfc/case_sensitive_php

Kind regards,
Jorg

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

Tue, 16 Jun 2026 23:02:25 +0000

Here's a thought - Instead of .phpc as an extension, why not <?phpc or
even <?psf (PHP source file). Explicitly tell the engine "nothing should be
before this other than a shebang, no further tags will be in this file.

That also solves the inadverted echo problem and would be fully BC.

Not convinced it would be useful, but it has fewer problems.

I could actually get behind an alternative tag that reads everything as
PHP. It would at least solve the problem of accidental output prior to the
opening tag, though I'm not sure how big of a problem that really is. Could
we expect any performance benefits from not having to parse for any closing
tags? I imagine it would be minuscule if anything

[RFC] Function Autoloading (mark 5)

Tue, 16 Jun 2026 22:55:48 +0000

Hi all,

This is (by my count) a 5th attempt at adding function autoloading to PHP.

RFC: https://wiki.php.net/rfc/function-autoloading-five-oh

PR: https://github.com/php/php-src/pull/22337

Looking forward to the discussion around this one!

-- pmj

I assume you saw my last attempt at this? :)

The general consensus was that spl autoloader needs to go and nobody wanted to see more added to it. That being said, maybe the list has changed its mind... hopefully.

— Rob

[RFC] Function Autoloading (mark 5)

Tue, 16 Jun 2026 22:22:46 +0000

Hey Paul,

Hi all,

This is (by my count) a 5th attempt at adding function autoloading to PHP.

RFC: https://wiki.php.net/rfc/function-autoloading-five-oh

PR: https://github.com/php/php-src/pull/22337

Looking forward to the discussion around this one!

-- pmj

What is the motivation to not do a second call to the function
autoloaders with "bar" (global namespace) when "bar()" is being called
in the Foo namespace and the initial call with "Foo\bar" doesn't resolve
to anything?

That would probably have much less rough edges, completely sidestepping
the issue here with Foo\bar() not being found.

Thanks,
Bob

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

Tue, 16 Jun 2026 22:19:46 +0000

Am 16.06.2026 um 20:43 schrieb Derick Rethans derick@php.net:

Am 16.06.2026 um 09:26 schrieb Davey Shafik me@daveyshafik.com:
<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:

The friction is real and a small targeted addition is worth
shipping. (what the RFC proposes)

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

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.

Did you generate this reply with an LLM? It certainly reads like that.

I'm asking because I find it an extremely rude thing to do, unless it is
to assist with language.

Because if people don't want to spend their own time and effort coming
with an argument, then I also don't find it necessary for me to reply to
them, or hear what they're saying.

cheers
Derick

Hi Derick,

Yes, I use AI but for assist - not to „copy-paste“ reply.

Reason for this: I’m native German and it’s easier for me to write an
answer with LLM instead of using google translator for words, which don’t
come to my mind.

To clarify my position with LLM: It’s a tool and not a placement.

Hendrik

Here's a thought - Instead of .phpc as an extension, why not <?phpc or even
<?psf (PHP source file). Explicitly tell the engine "nothing should be
before this other than a shebang, no further tags will be in this file.

That also solves the inadverted echo problem and would be fully BC.

Not convinced it would be useful, but it has fewer problems.

[RFC] Function Autoloading (mark 5)

Tue, 16 Jun 2026 22:09:18 +0000

Hi all,

This is (by my count) a 5th attempt at adding function autoloading to PHP.

Looking forward to the discussion around this one!

-- pmj

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

Tue, 16 Jun 2026 19:33:59 +0000

Am 16.06.2026 um 20:43 schrieb Derick Rethans derick@php.net:

Am 16.06.2026 um 09:26 schrieb Davey Shafik me@daveyshafik.com:

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

Did you generate this reply with an LLM? It certainly reads like that.

I'm asking because I find it an extremely rude thing to do, unless it is to assist with language.

Because if people don't want to spend their own time and effort coming with an argument, then I also don't find it necessary for me to reply to them, or hear what they're saying.

cheers
Derick

Hi Derick,

Yes, I use AI but for assist - not to „copy-paste“ reply.

Reason for this: I’m native German and it’s easier for me to write an answer with LLM instead of using google translator for words, which don’t come to my mind.

To clarify my position with LLM: It’s a tool and not a placement.

Hendrik

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

Tue, 16 Jun 2026 18:43:55 +0000

Am 16.06.2026 um 09:26 schrieb Davey Shafik me@daveyshafik.com:

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

Did you generate this reply with an LLM? It certainly reads like that.

I'm asking because I find it an extremely rude thing to do, unless it is to assist with language.

Because if people don't want to spend their own time and effort coming with an argument, then I also don't find it necessary for me to reply to them, or hear what they're saying.

cheers
Derick

[RFC] Separation of Third-Party Extension Documentation

Tue, 16 Jun 2026 18:26:41 +0000

What happens if the RFC fails? Do we just do nothing and let the PHP
manual deteriorate further?

Are there any abandoned extensions that make no sense to keep the
documentation for? Wouldn't it be wiser to prune the docs of these
abandoned extensions and then deal with the remaining per the outcome of
the RFC.

Regardless of whether this RFC passes or not, the documentation team
will continue trying to prune/archive documentation for genuinely
abandoned extensions where appropriate.

That said, it is not always straightforward. As these are third-party
extensions, we do not always have a clear picture of their maintenance
(or usage) status, and a lack of recent updates does not necessarily
mean an extension is no longer functional with current PHP versions.
Extensions could remain stable for years without requiring active changes.

Because of that, determining what should actually be removed or archived
requires careful consideration. This RFC would also help clarify the
boundaries and expectations around maintaining third-party extension
documentation going forward.

--
Regards,

Jordi Kroon

[RFC] Separation of Third-Party Extension Documentation

Tue, 16 Jun 2026 17:51:46 +0000

Hello,

I've opened an RFC to separate third-party extension documentation
(imagick, redis, mongodb, etc) from the official PHP manual, while
keeping the existing DocBook tooling and infrastructure.

Bundled extensions (pdo, curl, etc) are out of scope and stay in the
official PHP manual.

https://wiki.php.net/rfc/third_party_ext_documentation

It has been 2 weeks since the last major change.
I am planning to open voting this Friday (June 19).

--
Regards,

Jordi Kroon

What happens if the RFC fails? Do we just do nothing and let the PHP manual
deteriorate further?

Are there any abandoned extensions that make no sense to keep the
documentation for? Wouldn't it be wiser to prune the docs of these
abandoned extensions and then deal with the remaining per the outcome of
the RFC.

[RFC] Separation of Third-Party Extension Documentation

Tue, 16 Jun 2026 17:43:00 +0000

Hello,

I've opened an RFC to separate third-party extension documentation
(imagick, redis, mongodb, etc) from the official PHP manual, while
keeping the existing DocBook tooling and infrastructure.

Bundled extensions (pdo, curl, etc) are out of scope and stay in the
official PHP manual.

https://wiki.php.net/rfc/third_party_ext_documentation

It has been 2 weeks since the last major change.
I am planning to open voting this Friday (June 19).

--
Regards,

Jordi Kroon

[RFC] [Discussion] Literal Scalar Types

Tue, 16 Jun 2026 16:25:36 +0000

Hey Larry,

Am 16.06.2026 um 17:16 schrieb Larry Garfield larry@garfieldtech.com:

While this RFC works alongside the pattern matching proposal by Larry and Ilija, neither requires the other. The two are unrelated for several reasons.

So to answer your question, no, I am not looking for pattern matching. I see these as two distinct features that address different needs within the language.

I don't believe they are addressing entirely different needs. I believe the feature that static analysis tools support is pattern matching more than it is typing. The question for me becomes whether patterns be represented through types, or whether they should be matched against values.

Strictly denoting types and validating patterns are two separate concerns. One asks "What can I do with this?" while the other asks "Is this within expected bounds?". I am personally not against validating patterns within type declarations, as is supported in Typescript, Scala (I believe), and to an extent PHP with false|true. But I do believe they are different concerns.

I also think that, this being a form of pattern matching, if approved would set a direction for the pattern matching RFC to treat patterns more closely as types than assertions and guards (as their RFC currently proposes). I am again not saying this is a bad thing, but it is worth acknowledging.

Hi Sarina,

I don't think we disagree here. I already said above that I think
pattern matching should match against types with variable binding; this
actually makes pattern matching easier because to expand it, you just
have to expand the type system, and patterns get expanded for free.

However, I think this is a discussion for the pattern matching RFC, not
for the literal types RFC.

Cheers,
Seifeddine.

This is interesting. We've approached patterns as a coincidental superset of the type system. That is, (almost) any type declaration is a valid pattern, but not because patterns are types; because we've implemented patterns to mirror types.

Patterns as types would be a completely different approach. I can see the appeal, but there's a number of issues there:

Performance. Patterns do a lot more work than a type check right now. If patterns cropped up in function signatures all over the place, that would have a notable, though currently unclear and hard to predict, impact on performance. (Far more inconsistent than, say, reified generics would have...)

The performance impact is certainly lower than manually validating all over the place.
Also, this would be a good motivation to invest into moving the type checks for known functions onto the caller side, and eliding them completely if the variable is unmodified. By now we have knowledge when variables can definitely not leak (are no references, no varvars or extract etc. are used) and check whether and what they are being assigned during the lifetime of the function.

In fact, using "int & < 10 & > 1" would give pretty strong bounds for opcaches data flow analysis to use too, giving much better hints at what integers will never be promoted to float, reducing the amount of guards necessary in JIT for example. An int which never can be < 0 for example saves a bounds check in one direction as well when working with packed arrays.
I.e. depending on the patterns and their integration into opcache quite a bit of potential could be unlocked.

But yes, you can always find worst case performances.

Complexity. Expanding the type system to full patterns seems like it would be... hard. And possibly internal-API breaking. I could be completely wrong here, but it sounds like a fairly drastic change.

Why would it be particularly hard? We already have dedicated types APIs for stuff like type intersection and union. I don't think there would be a lot of impact.

Repeatability. For this to work, I think it would have to include type definitions, which have always hit a discussion wall in the past as no one can agree on their design. Something like:

type positiveInt = int & >0;
type UserId = int;
type order = 'asc'|'desc';

function foo(positiveInt $val) { ... } // Guaranteed to be an integer greater than 0

function bar(UserId $id) { ... } // Would this accept a positiveInt? Debatable.

There's a sizable rabbit hole here. One could argue even that for scalar literal types we should have proper type defs.

From the perspective of an autoloader, a type name is just like any other class name.
This is more composers problem to solve (they possibly could include a per-namespace fallback to a default.php or something, where you'd define all types of a namespace in).
We should have type names eventually, but I consider them separate from the basic pattern feature. Should be done, but separate RFC with its own concerns, and I also suppose a pretty simple RFC actually!

Variable binding. Let me be clear: Variable binding is the feature that makes pattern matching worthwhile. It's the reason we started working on it; we believe it is a prerequisite for properly implementing ADTs/"tagged enums." So even if patterns become types, there will still be a need for an extended variable binding syntax that works only inline, not as part of a type declaration. What the complexity impact of that would be, I have no idea.

I don't think we would need to include binding in a first version of this.

If there is a consensus to go down this rabbit hole, I am not opposed to it. But it's a very deep rabbit hole, and exploring it would guarantee that neither patterns nor scalar literal types make it into this version. It would probably also entail 3-4 RFCs total, all of which would be kind of half-arsed on their own because they're part of a set; and PHP has been extremely, extremely bad at coordinating and working with that in the past. (Maybe a place for working groups?)

I also don't think that pattern matching needs particular changes to fit this. The syntax of pattern matching is pretty fine and could be just 1:1 translated to function args.

--Larry Garfield

Thanks,
Bob

Containers. (was Re: Two-step creation for PHP modules)

Tue, 16 Jun 2026 15:22:06 +0000

Le 16/06/2026 à 06:45, Michael Morris a écrit :

Namespaces being just a globally accessible and define-able symbols
system is exactly why, so far, a PHP package cannot define "private
internal" code. The way the language works already allows
autoload-hijacking in order to override code from external libs, or even
hack the visibility (like removing "final" or "private" keywords before
autoloading the file...).

PHP has never kept people from shooting themselves in the foot. And in the
past it's came with some big guns too (Register Globals in PHP 3 anyone?).
Enforcing namespace visibility will come at a cost in performance, and it
won't be enough to stop people from shooting themselves because PHP code is
quite mutable. I don't see much of a point in trying to guide people's
coding, especially in a language that doesn't have a set paradigm. That
is, in Java, you're using classes. In PHP you can approach things that way,
but you write purely procedurally. You can use the language as it was
originally conceived - a templating language.

I think it's morally good to bring new features to the core that disallow
someone from shooting themselves in the foot. Readonly classes, property
hooks, etc., are methods for maintainers to be able to stricten their code
so that end users don't shoot themselves in the foot. Yet we have the
Reflection API that permits a huge lot of things, and combining with
autoload hacking or bounded closures, it means that all these requirements,
strictening tools, etc., are contracts we sign with maintainers. If
someone uses any hacky tool built in PHP to override its native behavior,
it's at their own risk. But the language allows it.

With my suggestion for modules, having all structures being declared
globally but with a prefix still allows someone to hack into it. It just
lowers the pressure on how it's developed in the core, in order for it to
be both simple to use, but also simpler to implement. Doesn't prevent feet
shots, but has a big warning sign nonetheless.

When you say modules, what are talking about, because multiple languages
implement "modules" in different ways. JavaScript is the most well known,
but Go also has modules and they are quite different and support versioning
out of the box. In each of these examples there is a requirement that the
programmer write code to import the modules at some place either in the
project (Go) or in every bloody file in the project (JavaScript). PHP
doesn't require this, instead autoloading symbol definitions as they are
encountered.

There are different terms available for the things we talk about, so as a
reminder to the two/three people reading this message:

Module = file, similar to JS. This implies that everything defined
in the file is private, unless "publicly exposed", either via a "public"
keyword (as Larry suggests in his modules-brainstorming document), or an
"export" statement (similar to JS/TS).

Module = package, in that case, this means that a module is composed
of several files, but a module/package needs an entrypoint to define its
components. Larry's aforementioned idea is about using an INI file as
entrypoint that prevents double-loading of a list of files, but this could
be implemented with other methods: my proposal for "module = file" could
add a "package" system without a need for an INI file, and based purely on
the list of publicly available structures from the main imported file, but
implies a bidirectional relationship between the "main package file" (aka
"entrypoint") and the "package-included-only file". It's just a different
approach.

None of these approaches removes namespaces, and considering my first idea
and re-thinking it after all the comments in here, I think focusing on
"using namespaces for that" is definitely the best approach. My proposal
still stands, it just needs an update to better use namespaces for that
need.

NPM (not Node, node is the engine not the package/dependency manager) does
this using aliases. PHP doesn't have a way to alias symbols at compile
time. It would be nice if it did - I've suggested it as a parameter to
include not knowing at the time of the suggestion that include isn't a
function, it's a statement, so include "file.php" is the same as
include("file.php"). Setting that aside, PHP projects rarely execute the
include themselves - they let an autoloader handle it, so the autoloader
must know which version to load. This isn't something that even NPM does -
it just aliases and makes both libraries available. The caller still must
specify which library is being pulled in.

Node modules have a single point of entry, defined in the package.json
file but usually index.js. In most Node packages this index.js imports all
the public parts of the package and immediately exports them. Further, an
import in node is an object (as is everything in JavaScript) that
corresponds to that file. Hence

import { foo, bar } from 'MyPackage';

This is using JavaScripts dereference mechanic to pluck members of an
object into the current symbol table. I could go on, but I think it's more
on topic to just say that Node's import/export mechanic, elegant as it
looks, is highly bound to JavaScript's scope rules and how its symbol
table works. These aren't compatible with PHP.

I'm a bit familiar with Node.js's import model. PHP could be partly
compatible with this in the future, but complete scoped encapsulation of a
single PHP file is too much of a paradigm change for PHP itself. My
proposal is making this "private" by prepending a null character and hash
to all "included modules" whatever their kind, so that it feels private,
but still behaves similarly to how PHP currently works.
Less maintenance for the core team, zero BC break (purely additive and
opt-in), can be transparent for the end-user (and is transparent for
transient dependencies), still overridable and hackable by developers. Some
of the reasons why PHP became famous in the first place.

For one, PHP has two symbol tables - one for variables (which is why all
variables start with $ ) and one for everything else. Variables are
affected by function scope, nothing else is. For example, if you define a
function within a function in JavaScript that function will be private to
the function it is defined in - it can't be seen in other scopes. In PHP
the function will be visible on the symbol table.

For another, Node gives each file its own module scope. To move a symbol
from one file to another you should use export and import. This creates a
clear chain of custody for objects and symbols, but by God it also creates
a LOT of boilerplate that the PHP community has no interest in replicating.

Without the chain of custody you rapidly run into trouble. It doesn't
matter if you try to allow the user to put a prefix on the namespace as I
once suggested, or have PHP's engine prefix it automagically somehow - you
still need to correctly disambiguate every blasted reference to that
namespace. This is no easy task - take a look at the code of Strauss -
https://github.com/BrianHenryIE/strauss That project allows you to
rewrite a package with a new namespace, in effect doing it in userland. But
as a precaution it prefixes every single package imported and severs the
tie back to the original packagist. Strauss is used by several WordPress
plugins to make composer library use possible while still remaining
portable between WordPress sites.

Interesting, and auto-prefixing namespaces for module=packages systems is
IMO the easiest way to implement this without breaking the compiler nor the
engine. It keeps everything as-is, and visually provides all that's needed
for a "modules/packages" system to work: encapsulated private structures,
an explicit public API, and the ability to load the same structures in the
same namespaces because they are internally hidden with a hash, similarly
to anonymous classes.

The only drawback of having modules like that would be that final
dependency trees in Composer would be non-flat, but again, I think this
non-flat system should be opt-in. Similarly to how flat systems are
opt-in in the Node.js ecosystem (and trust me, I've tried to enforce
"flat" dependencies resolutions in certain Node projects, and it's a
huge hassle). Luckily, the PHP ecosystem is quite fine so far, compared
to Node, and I would definitely keep the "flat" system in Composer for
as long as possible, and make non-flat resolutions only case-specific
(which is rare, and usually framework-dependent, like with Wordpress
plugins for instance).

I don't think it's a reasonable ask of Composer or any other dependency
manager to try to resolve this without having a clear binding map like the
one JavaScript forces you to create by how its module system works.

Composer doesn't have to change, because modules might be autoloadable.
Whatever the solution found: if it's a bidirectional relationship (meaning
any included file contains information on the "package" it's in, guiding to
the entrypoint) or with a config file (like with an INI file), it can be
built-in, and Composer would be compatible as long as loaded structures are
public and not internal to the module.

This is the Container thread - I changed the subject line on my previous
reply although I did include (was: ) so that people could track I was
forking.

I don't have much to add beyond my previous post. I haven't heard from
anyone with engine experience about the feasibility or difficulty of what I
propose. To review (for anyone just joining but missing the previous
message)

The user signals to the engine they want to include a php file AND
process it independent of the current execution environment. No shared user
defined symbols or variables.

That file returns an interface so that the calling thread can talk to
the child.

As the processes reside on different threads these calls will need to
be asynchronous to be optimal, otherwise the caller will be in a blocked
state while the child executes the called method. It can work without the
PHP Async / Await RFC's conclusion, but it won't be in ideal form without
it.

Containers provide process isolation. Say I have a WordPress plugin that I
want to use composer libraries with. Say, Guzzle. I can write my own
container interface without touching Guzzle's code exposing the parts of
Guzzle I need for my plugin. Since WordPress has no current core composer
support I would need to carry a loader in my distro to be ran on the
install hook of the plugin, bringing in composer and letting it in turn
pull the libraries that I need to use. If someone later writes a plugin
that uses an incompatible version of Guzzle that doesn't matter - even if
they lazily load it into the main symbol table by not using a container.
My plugin is isolated.

That isolation comes at a price. Each plugin has an independent vendor
directory with no way to resolve complete redundancy. At least not in
WordPress, which has no current composer implementation in core (I'm on the
wp trac in a thread discussing it though).

There are open questions though that must be answered before this
container idea is seriously explored. Most critical, can PHP be made to
handle an object passing from one thread to another? That is, continuing
from the example above, can a client instance from one GuzzleContainer
coexist on the main thread with a client instance from a different
container and referencing different code? Or will methods be unable to
cross the barrier? What are the implications for the Reflection API and
using it to examine an object that originated from another process thread
referencing symbols that don't exist on the current thread?

The idea of containers is simple to state - but the implications are
profound and might be unworkable. I simply don't know enough about the PHP
engine to know.

This seems completely out of a "modules" scope to me: threading comes with
a huge cost (like state interoperability, thread healthchecks, memory
usage, and many other things), and this brings a lot of complexity that is
not needed yet IMO. If someone wants to "sandbox" PHP somehow, it's already
possible to execute another PHP script from inside a PHP script via CLI,
and passing arguments to it, but there's no back-and-forth communication,
only a "request-response-like" system.

However complex threading is, the complexity of aliasing is going to be
higher. I've walked down this thought experiment several times in the last
4 years. Threading isn't easy, but the work is in progress by Edmond HT -
https://wiki.php.net/rfc/true_async

Containers, as I'm proposing them, rest on the foundation of this already
in progress RFC which in turn builds on ReactPHP, AMPHP, Swoole and others.

[RFC] [Discussion] Literal Scalar Types

Tue, 16 Jun 2026 15:16:34 +0000

While this RFC works alongside the pattern matching proposal by Larry and Ilija, neither requires the other. The two are unrelated for several reasons.

So to answer your question, no, I am not looking for pattern matching. I see these as two distinct features that address different needs within the language.

I don't believe they are addressing entirely different needs. I believe the feature that static analysis tools support is pattern matching more than it is typing. The question for me becomes whether patterns be represented through types, or whether they should be matched against values.

Strictly denoting types and validating patterns are two separate concerns. One asks "What can I do with this?" while the other asks "Is this within expected bounds?". I am personally not against validating patterns within type declarations, as is supported in Typescript, Scala (I believe), and to an extent PHP with false|true. But I do believe they are different concerns.

I also think that, this being a form of pattern matching, if approved would set a direction for the pattern matching RFC to treat patterns more closely as types than assertions and guards (as their RFC currently proposes). I am again not saying this is a bad thing, but it is worth acknowledging.

Hi Sarina,

I don't think we disagree here. I already said above that I think
pattern matching should match against types with variable binding; this
actually makes pattern matching easier because to expand it, you just
have to expand the type system, and patterns get expanded for free.

However, I think this is a discussion for the pattern matching RFC, not
for the literal types RFC.

Cheers,
Seifeddine.

This is interesting. We've approached patterns as a coincidental superset of the type system. That is, (almost) any type declaration is a valid pattern, but not because patterns are types; because we've implemented patterns to mirror types.

Patterns as types would be a completely different approach. I can see the appeal, but there's a number of issues there:

Performance. Patterns do a lot more work than a type check right now. If patterns cropped up in function signatures all over the place, that would have a notable, though currently unclear and hard to predict, impact on performance. (Far more inconsistent than, say, reified generics would have...)
Complexity. Expanding the type system to full patterns seems like it would be... hard. And possibly internal-API breaking. I could be completely wrong here, but it sounds like a fairly drastic change.
Repeatability. For this to work, I think it would have to include type definitions, which have always hit a discussion wall in the past as no one can agree on their design. Something like:

type positiveInt = int & >0;
type UserId = int;
type order = 'asc'|'desc';

function foo(positiveInt $val) { ... } // Guaranteed to be an integer greater than 0

function bar(UserId $id) { ... } // Would this accept a positiveInt? Debatable.

There's a sizable rabbit hole here. One could argue even that for scalar literal types we should have proper type defs.

Variable binding. Let me be clear: Variable binding is the feature that makes pattern matching worthwhile. It's the reason we started working on it; we believe it is a prerequisite for properly implementing ADTs/"tagged enums." So even if patterns become types, there will still be a need for an extended variable binding syntax that works only inline, not as part of a type declaration. What the complexity impact of that would be, I have no idea.

If there is a consensus to go down this rabbit hole, I am not opposed to it. But it's a very deep rabbit hole, and exploring it would guarantee that neither patterns nor scalar literal types make it into this version. It would probably also entail 3-4 RFCs total, all of which would be kind of half-arsed on their own because they're part of a set; and PHP has been extremely, extremely bad at coordinating and working with that in the past. (Maybe a place for working groups?)

--Larry Garfield

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

Tue, 16 Jun 2026 14:53:08 +0000

The friction is real and a small targeted addition is worth
shipping. (what the RFC proposes)

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

The friction is not real, or not worth a language change at all.

I also am in camp 3. I basically never type <?php myself. My IDE does it for me when I create a file. This is a non-issue, and the proposed solution, as others have explained, has many issues and gotchas.

One useful part of Alex's module proposal was a file type that had stricter rules about what it could do; basically it had to follow PSR-1. I think there could be potential in that concept, but it wouldn't be triggered by a different file name; it would be triggered by, say, <?phpo (PHP Only), or some other prefix that indicates the whole file must be code, no ?> allowed, cannot have top-level output or code, etc. The idea needs some development, but I could see that having use in a way that doesn't break BC.

But pivoting off the file name is a non-starter.

--Larry Garfield

Containers. (was Re: Two-step creation for PHP modules)

Tue, 16 Jun 2026 14:29:06 +0000

Le 16/06/2026 à 06:45, Michael Morris a écrit :

Namespaces being just a globally accessible and define-able symbols
system is exactly why, so far, a PHP package cannot define "private
internal" code. The way the language works already allows
autoload-hijacking in order to override code from external libs,
or even
hack the visibility (like removing "final" or "private" keywords
before
autoloading the file...).
PHP has never kept people from shooting themselves in the foot. And in
the past it's came with some big guns too (Register Globals in PHP 3
anyone?). Enforcing namespace visibility will come at a cost in
performance, and it won't be enough to stop people from shooting
themselves because PHP code is quite mutable. I don't see much of a
point in trying to guide people's coding, especially in a language
that doesn't have a set paradigm. That is, in Java, you're using
classes. In PHP you can approach things that way, but you write purely
procedurally. You can use the language as it was originally conceived

a templating language.

I think it's morally good to bring new features to the core that
disallow someone from shooting themselves in the foot. Readonly classes,
property hooks, etc., are methods for maintainers to be able to stricten
their code so that end users don't shoot themselves in the foot. Yet we
have the Reflection API that permits a huge lot of things, and combining
with autoload hacking or bounded closures, it means that all these
requirements, strictening tools, etc., are contracts we sign with
maintainers. If someone uses any hacky tool built in PHP to override its
native behavior, it's at their own risk. But the language allows it.

With my suggestion for modules, having all structures being declared
globally but with a prefix still allows someone to hack into it. It just
lowers the pressure on how it's developed in the core, in order for it
to be both simple to use, but also simpler to implement. Doesn't prevent
feet shots, but has a big warning sign nonetheless.

When you say modules, what are talking about, because multiple
languages implement "modules" in different ways. JavaScript is the
most well known, but Go also has modules and they are quite different
and support versioning out of the box. In each of these examples there
is a requirement that the programmer write code to import the modules
at some place either in the project (Go) or in every bloody file in
the project (JavaScript). PHP doesn't require this, instead
autoloading symbol definitions as they are encountered.

There are different terms available for the things we talk about, so as
a reminder to the two/three people reading this message:

Module = file, similar to JS. This implies that everything defined
in the file is private, unless "publicly exposed", either via a
"public" keyword (as Larry suggests in his modules-brainstorming
document), or an "export" statement (similar to JS/TS).
Module = package, in that case, this means that a module is composed
of several files, but a module/package needs an entrypoint to define
its components. Larry's aforementioned idea is about using an INI
file as entrypoint that prevents double-loading of a list of files,
but this could be implemented with other methods: my proposal for
"module = file" could add a "package" system without a need for an
INI file, and based purely on the list of publicly available
structures from the main imported file, but implies a bidirectional
relationship between the "main package file" (aka "entrypoint") and
the "package-included-only file". It's just a different approach.

None of these approaches removes namespaces, and considering my first
idea and re-thinking it after all the comments in here, I think focusing
on "using namespaces for that" is definitely the best approach. My
proposal still stands, it just needs an update to better use namespaces
for that need.

NPM (not Node, node is the engine not the package/dependency manager)
does this using aliases. PHP doesn't have a way to alias symbols at
compile time. It would be nice if it did - I've suggested it as a
parameter to include not knowing at the time of the suggestion that
include isn't a function, it's a statement, so include "file.php" is
the same as include("file.php"). Setting that aside, PHP projects
rarely execute the include themselves - they let an autoloader handle
it, so the autoloader must know which version to load. This isn't
something that even NPM does - it just aliases and makes both
libraries available. The caller still must specify which library is
being pulled in.

Node modules have a single point of entry, defined in the package.json
file but usually index.js. In most Node packages this index.js imports
all the public parts of the package and immediately exports them.
Further, an import in node is an object (as is everything in
JavaScript) that corresponds to that file. Hence

import { foo, bar } from 'MyPackage';

This is using JavaScripts dereference mechanic to pluck members of an
object into the current symbol table. I could go on, but I think it's
more on topic to just say that Node's import/export mechanic, elegant
as it looks, is highly bound to JavaScript's scope rules and how its
symbol table works. These aren't compatible with PHP.

I'm a bit familiar with Node.js's import model. PHP could be partly
compatible with this in the future, but complete scoped encapsulation of
a single PHP file is too much of a paradigm change for PHP itself. My
proposal is making this "private" by prepending a null character and
hash to all "included modules" whatever their kind, so that it
/feels/ private, but still behaves similarly to how PHP currently works.
Less maintenance for the core team, zero BC break (purely additive and
opt-in), can be transparent for the end-user (and is transparent for
transient dependencies), still overridable and hackable by developers.
Some of the reasons why PHP became famous in the first place.

For one, PHP has two symbol tables - one for variables (which is why
all variables start with $ ) and one for everything else. Variables
are affected by function scope, nothing else is. For example, if you
define a function within a function in JavaScript that function will
be private to the function it is defined in - it can't be seen in
other scopes. In PHP the function will be visible on the symbol table.

For another, Node gives each file its own module scope. To move a
symbol from one file to another you should use export and import. This
creates a clear chain of custody for objects and symbols, but by God
it also creates a LOT of boilerplate that the PHP community has no
interest in replicating.

Without the chain of custody you rapidly run into trouble. It doesn't
matter if you try to allow the user to put a prefix on the namespace
as I once suggested, or have PHP's engine prefix it automagically
somehow - you still need to correctly disambiguate every blasted
reference to that namespace. This is no easy task - take a look at the
code of Strauss - https://github.com/BrianHenryIE/strauss That project
allows you to rewrite a package with a new namespace, in effect doing
it in userland. But as a precaution it prefixes every single package
imported and severs the tie back to the original packagist. Strauss
is used by several WordPress plugins to make composer library use
possible while still remaining portable between WordPress sites.

Interesting, and auto-prefixing namespaces for module=packages systems
is IMO the easiest way to implement this without breaking the compiler
nor the engine. It keeps everything as-is, and visually provides all
that's needed for a "modules/packages" system to work: encapsulated
private structures, an explicit public API, and the ability to load the
same structures in the same namespaces because they are internally
hidden with a hash, similarly to anonymous classes.

The only drawback of having modules like that would be that final
dependency trees in Composer would be non-flat, but again, I think
this
non-flat system should be opt-in. Similarly to how flat systems are
opt-in in the Node.js ecosystem (and trust me, I've tried to enforce
"flat" dependencies resolutions in certain Node projects, and it's a
huge hassle). Luckily, the PHP ecosystem is quite fine so far,
compared
to Node, and I would definitely keep the "flat" system in Composer
for
as long as possible, and make non-flat resolutions only case-specific
(which is rare, and usually framework-dependent, like with Wordpress
plugins for instance).

I don't think it's a reasonable ask of Composer or any other
dependency manager to try to resolve this without having a clear
binding map like the one JavaScript forces you to create by how its
module system works.

Composer doesn't have to change, because modules might be autoloadable.
Whatever the solution found: if it's a bidirectional relationship
(meaning any included file contains information on the "package" it's
in, guiding to the entrypoint) or with a config file (like with an INI
file), it can be built-in, and Composer would be compatible as long as
loaded structures are public and not internal to the module.

This is the Container thread - I changed the subject line on my
previous reply although I did include (was: ) so that people could
track I was forking.

I don't have much to add beyond my previous post. I haven't heard from
anyone with engine experience about the feasibility or difficulty of
what I propose. To review (for anyone just joining but missing the
previous message)

The user signals to the engine they want to include a php file AND
process it independent of the current execution environment. No shared
user defined symbols or variables.

That file returns an interface so that the calling thread can talk
to the child.

As the processes reside on different threads these calls will need
to be asynchronous to be optimal, otherwise the caller will be in a
blocked state while the child executes the called method. It can work
without the PHP Async / Await RFC's conclusion, but it won't be in
ideal form without it.

Containers provide process isolation. Say I have a WordPress plugin
that I want to use composer libraries with. Say, Guzzle. I can write
my own container interface without touching Guzzle's code exposing the
parts of Guzzle I need for my plugin. Since WordPress has no current
core composer support I would need to carry a loader in my distro to
be ran on the install hook of the plugin, bringing in composer and
letting it in turn pull the libraries that I need to use. If someone
later writes a plugin that uses an incompatible version of Guzzle that
doesn't matter - even if they lazily load it into the main symbol
table by not using a container. My plugin is isolated.

That isolation comes at a price. Each plugin has an independent vendor
directory with no way to resolve complete redundancy. At least not in
WordPress, which has no current composer implementation in core (I'm
on the wp trac in a thread discussing it though).

There are open questions though that must be answered before this
container idea is seriously explored. Most critical, can PHP be made
to handle an object passing from one thread to another? That is,
continuing from the example above, can a client instance from one
GuzzleContainer coexist on the main thread with a client instance from
a different container and referencing different code? Or will methods
be unable to cross the barrier? What are the implications for the
Reflection API and using it to examine an object that originated from
another process thread referencing symbols that don't exist on the
current thread?

The idea of containers is simple to state - but the implications are
profound and might be unworkable. I simply don't know enough about the
PHP engine to know.

This seems completely out of a "modules" scope to me: threading comes
with a huge cost (like state interoperability, thread healthchecks,
memory usage, and many other things), and this brings a lot of
complexity that is not needed yet IMO. If someone wants to "sandbox" PHP
somehow, it's already possible to execute another PHP script from inside
a PHP script via CLI, and passing arguments to it, but there's no
back-and-forth communication, only a "request-response-like" system.

[RFC] Working Groups

Tue, 16 Jun 2026 13:40:18 +0000

Anything that doesn't need special powers can more efficiently be
organized without the overhead of the initial RFC, as can also be
seen by The PHP Foundation planning to launch 6 “special interest
groups” in the remainder of 2026 without needing to involve the PHP
project:

https://thephp.foundation/blog/2026/06/11/integrating-community-
feedback-into-foundation-strategy-part2/#community-special-interest-
groups

I'm aware of the PHP Foundation special interest groups, and Elizabeth
and I discussed them before I opened the Working Groups RFC for
discussion. We agreed they do not cover the same ground as the Working
Groups RFC. By design, the PHP Foundation SIGs have no operational or
governance authority over the PHP Project. There can be cross-
pollination and collaboration between the initiatives, but the SIGs
are external, community-focused, interest groups, while PHP WGs are
internal, PHP Project-focused, operational groups.

My 2cents in the form of questions (because I might have missed something):

Since the PHPF's role is to support, help and discuss, then shouldn't
PHPF operatives be excluded from voting on RFCs, whatever the involved
WG? It would ensure that the PHP voters (aka "/The community that
includes contributors and core team members/") can take decisions
without the PHPF being able to intervene if there's a disagreement
between the two groups, I guess...?

This RFC does not impose any restrictions or limitations on the PHP
Foundation or its contractors. They're welcome to create and participate
in working groups, and I never want to exclude them from voting on RFCs.
I'm not sure what problem that would solve.

And similarly, shouldn't there be a mandatory consultation from the PHP
community when the PHPF actually operates on something that impacts the
community on non-RFC-mandatory-operations, like marketing,
communication, etc.? I mean, if at some point the PHPF communicates on
the web on something the PHP community would disagree with (concluded
via a vote of whatever sort), shouldn't the PHPF, as a "consultative
agency", have to update their acts and productions to fit to the
community's views? (that would solve parts of the issues with the recent
hot discussions on a certain link to a certain platform on PHP's
website, for example).

This question doesn't seem related to the Working Groups RFC. The PHP
Foundation is transparent about its role, and they are making efforts to
be more transparent. As for the recent discussion about linking to
X/Twitter, that had nothing to do with the foundation at all, so I'm not
sure how you're making this connection.

All these questions are here because PHP has no official governance
other than the (sometimes vaguely) designated "PHP Community", and the
PHPF's role, from what I understand, is mostly to help the community to
decide and act on PHP-related tasks, but not directly decide nor act.

I might be off of some details, so feel free to correct me if I miss
something, if I'm mistaking, or if I misunderstand certain roles or
notions.

The Working Groups RFC is in no shape, way, or form an attempt to
control how the PHP Foundation operates within the PHP community. I have
zero problems with how they operate as an entity, and I trust their
leadership.

The WGs RFC exists to provide some (albeit loose) governance structure
to the PHP Project without entirely up-ending the status quo.

Cheers,
Ben

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

Tue, 16 Jun 2026 12:51:44 +0000

Following the pre-RFC discussion from late May [1], I'm moving the
"pure-code source files" proposal into formal RFC stage as

https://wiki.php.net/rfc/optional_php_tags <https://wiki.php.net/rfc/
optional_php_tags>

The single core motivation is:

Most new PHP files written today are pure code – framework classes,
autoloaded library code, console commands, configuration files, route
definitions. For these files the '<?php' opener carries no semantic
information; it is a vestige of PHP's templating heritage that every
file must repeat. PHP is the only modern mainstream language in which
this prefix is mandatory.

To which my response is "and that is a bad thing ... how?"

On the subject of ceremonial boilerplate ... Maybe it's changed in the
years since I had to work with it, but Perl modules had to end with "1;"
because they were evaluated as they were imported, and the whole module
had to return a truthy value to indicate that it had successfully
loaded. (Of course, any truthy value would work and '1' was merely
convention - TMTOWTDI.)

The mechanism is a single new opt-in file extension, .phpc, whose
semantics are: the file is parsed as pure PHP. The lexer enters
ST_IN_SCRIPTING on the first byte; no opening <?php is required.
A leading UTF-8 BOM and a CLI shebang are silently skipped. The
classic .php extension and every other code-loading path are
completely untouched - the change is strictly additive.

Reference implementation: PR against php/php-src (link in the RFC).
Patch is ~50 lines of straight-line C in
Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new
.phpt tests in Zend/tests/phpc/. Full regression run against Zend/,
ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/
(9836 tests): 0 failures, 0 modifications to any pre-existing test.

Pre-RFC feedback, addressed in the RFC document:

- Ben Ramsey on engine-vs-SAPI dispatch:
 own section explaining why include/require/Phar all live below
 SAPI and need engine-level handling. Ben's -p/stdin idea is
 adopted as Future Scope (a sister RFC after this one).

- Alex Rock on alternatives (env var, include_pure keyword,
 declare(pure=1)): each rebutted individually under "Rejected
 Alternatives".

- Bruce Weirdan on BC of the .phpc extension itself: own
 paragraph in the BC section, honest about the fact that I have
 NOT scanned public corpora; asking voters with private-codebase
 visibility for data points during Discussion.

- .pyc visual collision and scattered prior .phpc usage:
 addressed via a sub-vote on the extension name (.phpc / .phpp /
 .pcode / .phpx).

- Security (source-code exposure via misconfigured webservers,
 the historic .inc footgun): own section with mandatory
 documentation commitments and canonical Apache/Nginx/Caddy/
 FrankenPHP snippets in Appendix A.

- Boutell 2012 and Ohgaki 2014: own section distinguishing this
 proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward
to feedback, especially on:

- The Open Issues block in the RFC (extension name, real-world
 .phpc-in-use data, case-sensitivity on Windows/macOS).
- Anything in the Phar / OPcache surface I should test more
 thoroughly before voting opens.
- Whether the Security section's commitments are strong enough.

Thanks for reading,
Hendrik Mennen

[1] https://news-web.php.net/php.internals/131024 <https://news-
web.php.net/php.internals/131024

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

Tue, 16 Jun 2026 09:58:13 +0000

Le 16/06/2026 à 07:00, Hendrik Mennen a écrit :

Strictly additive
Sure thing, but it's not allowing any kind of BC, since
including ".phpc" files from older PHP versions would be
possible, and would be rendered as text instead of being
compiled...

- A library shipping .phpc files declares the target version
   in composer.json:
     "require": { "php": ">=8.6" }
- composer install fails at install time with a clear
   PHP-version error on lower versions. The .phpc file never
   reaches a running interpreter that doesn't understand it.
- Library authors who want to support older PHP versions
   don't ship .phpc files. Same constraint as readonly
   classes, property hooks, enums, etc.
- For non-Composer distribution (manual clone, raw .zip),
   the user is on their own - same as for any 8.x feature.

For application code (where the deployed PHP version is known)
the FC constraint is moot. For shared libraries it is real and
worth flagging in the RFC. I will add a Forward Compatibility
subsection covering this.

This list is a big reason to not implement your proposal: since it
breaks BC for everyone upgrading to the newer PHP version, it's putting
a huge burden to the entire ecosystem just to avoid disclosing PHP code
as text instead of parsing/compiling it.
(and side-note: it also forces potential users of ".phpc" extension to
change their code, though I doubt anyone is using this extension, and
checking Github isn't enough for that, considering the millions of
worldwide projects using PHP).
All that makes the RFC absolutely non-additive: you do not /add/ a
feature to the language, you are /changing/ how it behaves internally,
from not caring about file ext to making a big opinionated choice on one
particular extension name.

Reduced ceremony / First-class CLI scripts / Clearer file-mode
intent

These largely overlap with Kamil's earlier points; I'd rather
not re-litigate the same arguments inline. The Motivation
section is being rewritten this week to drop the four-bullet
framing entirely in favour of one honest sentence ("modern PHP
is overwhelmingly pure-code; <?php is a vestige for those files;
.phpc is the smallest mechanism to remove it opt-in") plus a
"what this RFC does NOT claim" subsection. If after that you
still see no value, that is a fair (3).

I don't think adding a file extension constraint adds any value to PHP.
Any file using "<?php" is just five characters at the beginning and all
works. Implementing this RFC would imply too much change on the language
and the ecosystem, just to avoid writing these five characters. That's
way too overkill.

Closing-tag-echo issue, having "?>" somewhere...

To clarify: this RFC does NOT try to solve that. ?> behaviour
inside a .phpc file is byte-for-byte identical to .php - drop-
out to inline mode is preserved, __halt_compiler() works, <?=
has no special meaning. The "What is unchanged" subsection of
the RFC says this; I will make it more prominent.

Noted

All existing ecosystem would have to adapt: Composer, IDEs,
web servers...

Concede partially. Adoption work is non-zero. The RFC's
position:

- Composer: PSR-4 autoloader already accepts a per-rule
   extension list; adding .phpc is documentation + a small
   Composer-side acknowledgement. RFC commits to opening
   that PR pre-landing.
- IDEs / static analysers: configure file modes by extension
   via their per-project config; one-line change per tool.
   RFC commits to opening tracking issues on day of vote
   acceptance.
- Web servers: explicit handler mapping or deny. Appendix A
   of the RFC ships canonical snippets for Apache, Nginx,
   Caddy, FrankenPHP.

You are right that adoption would be slow. I do not think
that disqualifies an additive opt-in feature, but I respect
that you do.

It's not about respecting what I do, or making the adoption quick, it's
about the relevance and impact of it.

Your RFC enforces a change in all the three elements on this list:
package managers, IDEs and web servers.

I think you already know that 80% of worldwide websites and apps are
using PHP.

You can not expect some hosting providers to advertise support for a
new PHP version if that version implies that they must update their
entire HTTP configuration on all their servers, VMs and so on, even if
it's a "one-liner" in your mind. I've been there on a small scale,
updating one machine that served dozens of domain names, and trust me,
it comes with a cost, and I'm a really smaller-cases user. Now scale
this to the worldwide web. It's just not rational at all.

This RFC not only enforces a "config change", it enforces lots of
companies to actually PAY for forward-compatibility before even
upgrading PHP.

In almost all its time, PHP's strength have been its ease to deploy and
configure, and here you're making deployment and configuration more
complex for the sake of removing five characters at the beginning of a
file. That's just too much.

Templating system based on PHP files [...] many such projects

Agreed, and .phpc proposes to harm none of them. It is opt-in
by filename. Template engines (compiled .php cache files
prefixed with <?php) are untouched; hand-written .phtml
templates are untouched; a legacy codebase that never adopts
.phpc loses nothing.

On the template part, /maybe/ a legacy codebase loses nothing. Maybe.

But all other arguments still stand.

Definition files (that I suggested in another internals
thread) [...] but even having "?>" from inside a function is
no issue

I have not read your Definition files thread yet; pointer
welcome. If that concept subsumes .phpc as a special case of
something broader, I would rather refine the bigger idea than
ship a smaller one that conflicts with it. Genuinely
interested.

You can read the thread there: https://externals.io/message/131171

It's on the internals mailing-list, feel free to check it out.

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

Tue, 16 Jun 2026 09:44:01 +0000

Le 16/06/2026 à 10:47, Hendrik Mennen a écrit :

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.

Wong: the ".phar" extension is just a reminder. A PHAR file is "just" a
PHP file that contains the "__HALT_COMPILER(); ?>" statement that tells
the engine and extension "where" to look to decompress the archive into
code, with an internal filesystem covered under the "phar://" stream.

Any PHAR file could use any extension, and ".phar" is just indicative.
It runs natively with PHP without needing an extension to be considered
as an archive.

I'm also camp-3, I think this feature doesn't add anything to PHP, and
breaks BC by introducing file extension as a constraint for conditional
parsing methods.

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

Tue, 16 Jun 2026 08:47:07 +0000

Am 16.06.2026 um 09:26 schrieb Davey Shafik me@daveyshafik.com:

<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

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

Tue, 16 Jun 2026 07:26:34 +0000

<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

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

Tue, 16 Jun 2026 05:04:23 +0000

Am 16.06.2026 um 06:52 schrieb Michael Morris tendoaki@gmail.com:

Am 15.06.2026 um 10:43 schrieb Kamil Tekiela <tekiela246@gmail.com mailto:tekiela246@gmail.com>:

Hi internals,

Following the pre-RFC discussion from late May [1], I'm moving the
"pure-code source files" proposal into formal RFC stage as

https://wiki.php.net/rfc/optional_php_tags

The mechanism is a single new opt-in file extension, .phpc, whose
semantics are: the file is parsed as pure PHP. The lexer enters
ST_IN_SCRIPTING on the first byte; no opening <?php is required.
A leading UTF-8 BOM and a CLI shebang are silently skipped. The
classic .php extension and every other code-loading path are
completely untouched - the change is strictly additive.

Reference implementation: PR against php/php-src (link in the RFC).
Patch is ~50 lines of straight-line C in
Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new
.phpt tests in Zend/tests/phpc/. Full regression run against Zend/,
ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/
(9836 tests): 0 failures, 0 modifications to any pre-existing test.

Pre-RFC feedback, addressed in the RFC document:

Ben Ramsey on engine-vs-SAPI dispatch:
own section explaining why include/require/Phar all live below
SAPI and need engine-level handling. Ben's -p/stdin idea is
adopted as Future Scope (a sister RFC after this one).

Alex Rock on alternatives (env var, include_pure keyword,
declare(pure=1)): each rebutted individually under "Rejected
Alternatives".

Bruce Weirdan on BC of the .phpc extension itself: own
paragraph in the BC section, honest about the fact that I have
NOT scanned public corpora; asking voters with private-codebase
visibility for data points during Discussion.

.pyc visual collision and scattered prior .phpc usage:
addressed via a sub-vote on the extension name (.phpc / .phpp /
.pcode / .phpx).

Security (source-code exposure via misconfigured webservers,
the historic .inc footgun): own section with mandatory
documentation commitments and canonical Apache/Nginx/Caddy/
FrankenPHP snippets in Appendix A.

Boutell 2012 and Ohgaki 2014: own section distinguishing this
proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward
to feedback, especially on:

The Open Issues block in the RFC (extension name, real-world
.phpc-in-use data, case-sensitivity on Windows/macOS).

Anything in the Phar / OPcache surface I should test more
thoroughly before voting opens.

Whether the Security section's commitments are strong enough.

Thanks for reading,
Hendrik Mennen

[1] https://news-web.php.net/php.internals/131024

I tried to catch up on this discussion last night. I see a lot of things that could go wrong with this, but I don't see a clear motivation for why would we want this change.

Reduced ceremony in pure-code files.
This is a moot point because after the change you still have the ceremony of adding .phpc to every file. Just unnecessary churn.

First-class CLI scripts.
Is this really a big concern? Is it going to work better? Are there things you cannot do today because of it?

Clearer file-mode intent.
We already have that. By convention many people add .php extension to pure PHP files, and .phtml to templates. It's not mandated by a language and people are free to choose their naming conventions.

Strictly additive.
That's not entirely true, but that's beside the point. Why is this one of the main motivations? We don't add things just because we can. They need to have a purpose.

We already have a good way of writing pure PHP code files. Just add 5 characters at the beginning of the file <?php and the rest of the file will be treated as PHP source code.

I would also like to echo what others said that PHP source code doesn't have to be within <?php. A text file will be compiled and interpreted by PHP as a print statement. Even in pure PHP code files you may want to escape the PHP context with ?>. Mandating that a file with a certain extension will have these restrictions is worse than having to start every file with <?PHP.

Regards,
Kamil

Hi Kamil,

Thanks for the substantive pushback - these are exactly the right
questions, and you're correct on more of them than the RFC as currently
worded admits.

Conceding upfront: "strictly additive" is a necessary property, not a
motivation. I leaned on it too much. Same for the three weaker arguments
(CLI ergonomics, convention clarity, ceremony shift) - none of them
alone justifies the mechanism.

The honest single-sentence motivation:

Most new PHP files written today are pure code (framework classes,
autoloaders, console commands, configuration). For those files the
<?php opener carries zero semantic information. PHP is the only
modern mainstream language where it is mandatory.

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:

The friction is real and a small targeted addition is worth
shipping. (what the RFC proposes)

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

The friction is not real, or not worth a language change at all.

That is a sharper question than re-litigating each motivation in turn,
and the answer determines whether to refine, pivot, or withdraw before
voting.

On your last point - that .phpc "restricts" PHP's text-as-print
feature - I think we agree more than disagree. .phpc would not change
.php behaviour at all. It is opt-in by filename. Authors who want the
templating shape keep using .php, ?> drop-out continues to work inside
.phpc, and the engine on existing files is byte-for-byte identical.
The "restriction" you describe (no top-of-file inline content;
<?php-as-tag rejected inside .phpc) is intentional - it is what makes
the mode meaningful for the cases that opt in.

I will update the RFC's Motivation section to reflect this
clarification in the next day or two so the rest of the Discussion
runs on the stronger framing rather than the weaker one I shipped
with.

Thanks again,
Hendrik

I don't get a vote, but mark me as opposed. If we ever do this, it needs to accompany something akin to JavaScript's strict mode which shards off several long standing warts that can't otherwise be gotten rid of because of BC. If we ever do a strict mode we'd better get it right and do it only once.

As it stands, there just isn't anything here other than lifting the need to type 5 characters at the start of every file. Worse, it could be closing a door we'll never see again.

Hi Michael,

Thanks - registered as opposed, conditional on "not bundled with
something larger". That conditional is a useful distinction.

The "you're closing the door on a bigger one-shot opportunity"
framing is worth answering directly. Two reasons I don't think it
holds:

.phpc and a hypothetical JS-strict-mode-style language cleanup
are best designed as orthogonal axes, not bundled. Strict mode
naturally lives in declare() or an attribute - both work inside
.php AND .phpc. Coupling "pure code" with "strict mode" would
force every .phpc adopter into strict mode whether they want it
or not, which is a much bigger ask than "opt into either
independently".
PHP already has per-file opt-ins that landed individually -
declare(strict_types=1), declare(ticks=1), readonly classes,
enums, property hooks. None of them consumed "the one-shot
file-mode slot" because there isn't one. .phpc adds one more
opt-in along a different axis; it does not consume design space
a future strict mode would need.

Bundling would make BOTH proposals harder, not easier. Strict mode
is contentious by design (every behaviour change has defenders) and
would extend Discussion and Voting by months or years. Removing the
opener does not have to wait on that.

If you have concrete ideas about what a PHP strict mode should
contain - which warts, which behaviours, which design - I would be
genuinely interested, separate from this RFC. That is a conversation
worth having on its own merits, in its own thread.

Regards,
Hendrik

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

Tue, 16 Jun 2026 05:00:02 +0000

Am 15.06.2026 um 12:16 schrieb Alex Rock pierstoval@gmail.com:

Le 15/06/2026 à 10:03, Hendrik Mennen a écrit :

Hi internals,

Following the pre-RFC discussion from late May [1], I'm moving the
"pure-code source files" proposal into formal RFC stage as

https://wiki.php.net/rfc/optional_php_tags

The mechanism is a single new opt-in file extension, .phpc, whose
semantics are: the file is parsed as pure PHP. The lexer enters
ST_IN_SCRIPTING on the first byte; no opening <?php is required.
A leading UTF-8 BOM and a CLI shebang are silently skipped. The
classic .php extension and every other code-loading path are
completely untouched - the change is strictly additive.

Reference implementation: PR against php/php-src (link in the RFC).
Patch is ~50 lines of straight-line C in
Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new
.phpt tests in Zend/tests/phpc/. Full regression run against Zend/,
ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/
(9836 tests): 0 failures, 0 modifications to any pre-existing test.

Pre-RFC feedback, addressed in the RFC document:

Ben Ramsey on engine-vs-SAPI dispatch:
own section explaining why include/require/Phar all live below
SAPI and need engine-level handling. Ben's -p/stdin idea is
adopted as Future Scope (a sister RFC after this one).

Alex Rock on alternatives (env var, include_pure keyword,
declare(pure=1)): each rebutted individually under "Rejected
Alternatives".

Bruce Weirdan on BC of the .phpc extension itself: own
paragraph in the BC section, honest about the fact that I have
NOT scanned public corpora; asking voters with private-codebase
visibility for data points during Discussion.

.pyc visual collision and scattered prior .phpc usage:
addressed via a sub-vote on the extension name (.phpc / .phpp /
.pcode / .phpx).

Security (source-code exposure via misconfigured webservers,
the historic .inc footgun): own section with mandatory
documentation commitments and canonical Apache/Nginx/Caddy/
FrankenPHP snippets in Appendix A.

Boutell 2012 and Ohgaki 2014: own section distinguishing this
proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward
to feedback, especially on:

The Open Issues block in the RFC (extension name, real-world
.phpc-in-use data, case-sensitivity on Windows/macOS).

Anything in the Phar / OPcache surface I should test more
thoroughly before voting opens.

Whether the Security section's commitments are strong enough.

Thanks for reading,
Hendrik Mennen

[1] https://news-web.php.net/php.internals/131024

I still disagree with this proposal, though I have no power anywhere, because IMO it doesn't bring lots of benefits compared to the issues it creates.

Side-note: the proposals I made about potential alternatives to include such files were only based on the "What if we still do this, but in another way?" motto. The bottom thought is that I disagree with the feature, but if it had to be done somehow, these suggestions are about how I would have done this, mostly to ensure better (IMO) BC and DX, nothing fancy or professional, just my random internet person's opinion :)

About the motivations, here are my comments:

Reduced ceremony in pure-code files

As you say: modern PHP code is already pure-PHP, and having to prepend "<?php" everywhere doesn't seem to be an issue for maintainers. I don't see why removing "<?php" would add any value.

First-class CLI scripts

You can already use shebang lines on PHP scripts and PHAR files, because what's after the shebang line is sent to the environment-based script that is requested from said shebang line. It's basically doing "env php {script file}" , therefore is already compatible with any shebang-line-compatible shell. Having a "<?php" just means it's PHP code. Having pure-PHP code without the opening tag wouldn't change a thing.

Clearer file-mode intent

It's not clearer, it's just moving the intent to the file extension rather than the file content itself. It's a really big DX change.
If I wanted a pure-PHP file with another extension, I could do it today by adding "<?php" in the file and it would be interpreted as PHP code without issues.
Here, the proposal is about allowing to shift a 30-plus-years-old working habit with PHP with something that is currently not intuitive neither expected. Adoption would definitely be complicated for lots of people, and if it's opt-in and doesn't bring lots of value, I'm not sure that many people would do it anyway.

Strictly additive

Sure thing, but it's not allowing any kind of BC, since including ".phpc" files from older PHP versions would be possible, and would be rendered as text instead of being compiled... This has a big impact on the ecosystem.
And by the way, about the ecosystem, here's my last comment on the motivations that definitely makes this proposal really hard to accept, at least for me: all existing ecosystem would have to adapt: Composer, IDEs, web servers, and so on. So it would be additive, indeed, but adoption would be extremely slow.

To me, one of the issues you are partially trying to fix is the potential closing-tag-echo issue, having "?>" somewhere indicating that PHP will echo something during the process. This issue can be solved with "Definition files" (that I suggested in another internals thread as a first-step towards Modules), but even having "?>" from inside a function is no issue: it just exposes a clear intent of "echo-ing something", and isn't really different than "echo <<<HTML " followed by a bunch of HTML for instance. IDEs may behave a bit differently with syntax highlighting, but modern IDEs are capable of injecting languages properly depending on lots of contextual metadata (and the "<<<HTML" heredoc syntax isn't random: IDEs can know that code inside this context is HTML). Your proposal would enforce using "echo" manually, while the "?>" syntax defines the same thing.
This system would also be useless for template systems based on PHP files, which are used in many legacy PHP projects for, well, legacy reasons ; I could tell you about many such projects I've been working on in the past 5 years only, and I'm one single person, so extrapolate this to worldwide devs, and you get more people that wouldn't care at all about pure-php files because it's useless to their stack.

Hi Alex,

Thanks for the detailed reply, and for the explicit "I still
disagree" - useful signal, and in the (1/2/3) framing from the
Kamil sub-thread you are at (3), which is exactly the kind of
direct answer I asked for. Even without voting power your
arguments will be read by voters, so engaging substantively.

The genuinely new concern in your reply that the RFC does not
yet address head-on is forward-compatibility. Taking that first.

Strictly additive
Sure thing, but it's not allowing any kind of BC, since
including ".phpc" files from older PHP versions would be
possible, and would be rendered as text instead of being
compiled...

You are correct. On PHP < target-version, a .phpc file pulled
in via require/include would be parsed by the existing lexer
in INITIAL state and emitted as inline content. This is the
standard 8.x adoption story in shape (a readonly class on 8.1
is a syntax error; a .phpc file on 8.5 is text emission), but
"text emission" is a worse failure mode than "syntax error"
because it can silently expose source code in a web context.

The realistic mitigation, which the RFC should make explicit
(and will, in the next revision):

A library shipping .phpc files declares the target version
in composer.json:
"require": { "php": ">=8.6" }
composer install fails at install time with a clear
PHP-version error on lower versions. The .phpc file never
reaches a running interpreter that doesn't understand it.
Library authors who want to support older PHP versions
don't ship .phpc files. Same constraint as readonly
classes, property hooks, enums, etc.
For non-Composer distribution (manual clone, raw .zip),
the user is on their own - same as for any 8.x feature.

For application code (where the deployed PHP version is known)
the FC constraint is moot. For shared libraries it is real and
worth flagging in the RFC. I will add a Forward Compatibility
subsection covering this.

Reduced ceremony / First-class CLI scripts / Clearer file-mode
intent

These largely overlap with Kamil's earlier points; I'd rather
not re-litigate the same arguments inline. The Motivation
section is being rewritten this week to drop the four-bullet
framing entirely in favour of one honest sentence ("modern PHP
is overwhelmingly pure-code; <?php is a vestige for those files;
.phpc is the smallest mechanism to remove it opt-in") plus a
"what this RFC does NOT claim" subsection. If after that you
still see no value, that is a fair (3).

Closing-tag-echo issue, having "?>" somewhere...

To clarify: this RFC does NOT try to solve that. ?> behaviour
inside a .phpc file is byte-for-byte identical to .php - drop-
out to inline mode is preserved, __halt_compiler() works, <?=
has no special meaning. The "What is unchanged" subsection of
the RFC says this; I will make it more prominent.

All existing ecosystem would have to adapt: Composer, IDEs,
web servers...

Concede partially. Adoption work is non-zero. The RFC's
position:

Composer: PSR-4 autoloader already accepts a per-rule
extension list; adding .phpc is documentation + a small
Composer-side acknowledgement. RFC commits to opening
that PR pre-landing.
IDEs / static analysers: configure file modes by extension
via their per-project config; one-line change per tool.
RFC commits to opening tracking issues on day of vote
acceptance.
Web servers: explicit handler mapping or deny. Appendix A
of the RFC ships canonical snippets for Apache, Nginx,
Caddy, FrankenPHP.

You are right that adoption would be slow. I do not think
that disqualifies an additive opt-in feature, but I respect
that you do.

Templating system based on PHP files [...] many such projects

Agreed, and .phpc proposes to harm none of them. It is opt-in
by filename. Template engines (compiled .php cache files
prefixed with <?php) are untouched; hand-written .phtml
templates are untouched; a legacy codebase that never adopts
.phpc loses nothing.

Definition files (that I suggested in another internals
thread) [...] but even having "?>" from inside a function is
no issue

I have not read your Definition files thread yet; pointer
welcome. If that concept subsumes .phpc as a special case of
something broader, I would rather refine the bigger idea than
ship a smaller one that conflicts with it. Genuinely
interested.

Thanks,
Hendrik

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

Tue, 16 Jun 2026 04:52:32 +0000

Am 15.06.2026 um 10:43 schrieb Kamil Tekiela tekiela246@gmail.com:

Hi internals,

Following the pre-RFC discussion from late May [1], I'm moving the
"pure-code source files" proposal into formal RFC stage as

https://wiki.php.net/rfc/optional_php_tags

The mechanism is a single new opt-in file extension, .phpc, whose
semantics are: the file is parsed as pure PHP. The lexer enters
ST_IN_SCRIPTING on the first byte; no opening <?php is required.
A leading UTF-8 BOM and a CLI shebang are silently skipped. The
classic .php extension and every other code-loading path are
completely untouched - the change is strictly additive.

Reference implementation: PR against php/php-src (link in the RFC).
Patch is ~50 lines of straight-line C in
Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new
.phpt tests in Zend/tests/phpc/. Full regression run against Zend/,
ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/
(9836 tests): 0 failures, 0 modifications to any pre-existing test.

Pre-RFC feedback, addressed in the RFC document:

Ben Ramsey on engine-vs-SAPI dispatch:
own section explaining why include/require/Phar all live below
SAPI and need engine-level handling. Ben's -p/stdin idea is
adopted as Future Scope (a sister RFC after this one).

Alex Rock on alternatives (env var, include_pure keyword,
declare(pure=1)): each rebutted individually under "Rejected
Alternatives".

Bruce Weirdan on BC of the .phpc extension itself: own
paragraph in the BC section, honest about the fact that I have
NOT scanned public corpora; asking voters with private-codebase
visibility for data points during Discussion.

.pyc visual collision and scattered prior .phpc usage:
addressed via a sub-vote on the extension name (.phpc / .phpp /
.pcode / .phpx).

Security (source-code exposure via misconfigured webservers,
the historic .inc footgun): own section with mandatory
documentation commitments and canonical Apache/Nginx/Caddy/
FrankenPHP snippets in Appendix A.

Boutell 2012 and Ohgaki 2014: own section distinguishing this
proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward
to feedback, especially on:

The Open Issues block in the RFC (extension name, real-world
.phpc-in-use data, case-sensitivity on Windows/macOS).

Anything in the Phar / OPcache surface I should test more
thoroughly before voting opens.

Whether the Security section's commitments are strong enough.

Thanks for reading,
Hendrik Mennen

[1] https://news-web.php.net/php.internals/131024

I tried to catch up on this discussion last night. I see a lot of things
that could go wrong with this, but I don't see a clear motivation for why
would we want this change.

Reduced ceremony in pure-code files.
This is a moot point because after the change you still have the ceremony
of adding .phpc to every file. Just unnecessary churn.

First-class CLI scripts.
Is this really a big concern? Is it going to work better? Are there things
you cannot do today because of it?

Clearer file-mode intent.
We already have that. By convention many people add .php extension to pure
PHP files, and .phtml to templates. It's not mandated by a language and
people are free to choose their naming conventions.

Strictly additive.
That's not entirely true, but that's beside the point. Why is this one of
the main motivations? We don't add things just because we can. They need to
have a purpose.

We already have a good way of writing pure PHP code files. Just add 5
characters at the beginning of the file <?php and the rest of the file will
be treated as PHP source code.

I would also like to echo what others said that PHP source code doesn't
have to be within <?php. A text file will be compiled and interpreted by
PHP as a print statement. Even in pure PHP code files you may want to
escape the PHP context with ?>. Mandating that a file with a certain
extension will have these restrictions is worse than having to start every
file with <?PHP.

Regards,
Kamil

Hi Kamil,

Thanks for the substantive pushback - these are exactly the right
questions, and you're correct on more of them than the RFC as currently
worded admits.

Conceding upfront: "strictly additive" is a necessary property, not a
motivation. I leaned on it too much. Same for the three weaker arguments
(CLI ergonomics, convention clarity, ceremony shift) - none of them
alone justifies the mechanism.

The honest single-sentence motivation:

Most new PHP files written today are pure code (framework classes,
autoloaders, console commands, configuration). For those files the
<?php opener carries zero semantic information. PHP is the only
modern mainstream language where it is mandatory.

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:

The friction is real and a small targeted addition is worth
shipping. (what the RFC proposes)

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

The friction is not real, or not worth a language change at all.

That is a sharper question than re-litigating each motivation in turn,
and the answer determines whether to refine, pivot, or withdraw before
voting.

On your last point - that .phpc "restricts" PHP's text-as-print
feature - I think we agree more than disagree. .phpc would not change
.php behaviour at all. It is opt-in by filename. Authors who want the
templating shape keep using .php, ?> drop-out continues to work inside
.phpc, and the engine on existing files is byte-for-byte identical.
The "restriction" you describe (no top-of-file inline content;
<?php-as-tag rejected inside .phpc) is intentional - it is what makes
the mode meaningful for the cases that opt in.

I will update the RFC's Motivation section to reflect this
clarification in the next day or two so the rest of the Discussion
runs on the stronger framing rather than the weaker one I shipped
with.

Thanks again,
Hendrik

I don't get a vote, but mark me as opposed. If we ever do this, it needs to
accompany something akin to JavaScript's strict mode which shards off
several long standing warts that can't otherwise be gotten rid of because
of BC. If we ever do a strict mode we'd better get it right and do it only
once.

As it stands, there just isn't anything here other than lifting the need to
type 5 characters at the start of every file. Worse, it could be closing a
door we'll never see again.

Containers. (was Re: Two-step creation for PHP modules)

Tue, 16 Jun 2026 04:45:01 +0000

Le 13/06/2026 à 19:14, Rowan Tommins [IMSoP] a écrit :

Namespaces in PHP are a bit of a hack - they prepend the stated
namespace
to all labels declared in the file, and the use statement allows the
fully
qualified name of a class, function or constant to be stated only once,
usually at the head of the file. It also allows aliasing, say if you
have a
"Parser" class out of two different packages - you can alias them as
"FooParser" and "BarParser". It looks like Java or JavaScript importing,
but it isn't.
A small correction: this is exactly the same way that namespaces work in
Java, with exactly the same implication: the fully qualified class name has
to be globally unique. Java's solution to isolating an entire set of names
is apparently to define an "Isolated ClassLoader":
https://www.javathinking.com/blog/what-is-an-isolated-classloader-in-java/

C# also has this model of namespaces, but allows you to isolate a set of
names from a particular "assembly" using an "extern alias" statement:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias

I suspect both mechanisms rely on details of their respective runtimes
that wouldn't translate to PHP, but in principle what we're looking for is
something similar.

Rowan Tommins
[IMSoP]

Namespaces being just a globally accessible and define-able symbols
system is exactly why, so far, a PHP package cannot define "private
internal" code. The way the language works already allows
autoload-hijacking in order to override code from external libs, or even
hack the visibility (like removing "final" or "private" keywords before
autoloading the file...).

PHP has never kept people from shooting themselves in the foot. And in the
past it's came with some big guns too (Register Globals in PHP 3 anyone?).
Enforcing namespace visibility will come at a cost in performance, and it
won't be enough to stop people from shooting themselves because PHP code is
quite mutable. I don't see much of a point in trying to guide people's
coding, especially in a language that doesn't have a set paradigm. That
is, in Java, you're using classes. In PHP you can approach things that way,
but you write purely procedurally. You can use the language as it was
originally conceived - a templating language.

After 18 years of PHP coding, including 15 years as a professional, I've
seen a huge lot of legacy PHP projects that benefit the language's
flexibility. Sure thing many of businesses could succeed thanks to being
able to override almost everything (contrary to stricter languages), but
maintaining these codebases with up-to-date versions of PHP, or
3rd-party libs, is so much of a hassle that, at some point, lots of
maintainers are going more and more into adding new things into PHP that
enforce a bit more strictness, opt-in of course. Some other libs (I'm
thinking about EasyAdmin, in the Symfony ecosystem, for example) have
even made the choice to close pretty much everything and provide
"maintainable" public entrypoints, enforcing the Open/Close principle
with a strict approach (immutable final classes, stricter options and
arguments, etc.). It has its pros and cons, and can be frustrating for
some devs, but the main goal was to make maintenance a bit easier for
the core devs so that they are not forced to maintain BC on too many
layers.

Introducing Modules, whether they are based on namespaces or not, would
help maintainers, I think, and could reinvent how we think of PHP
packages, while still keeping PHP what it has always been because it
would be opt-in for maintainers.

When you say modules, what are talking about, because multiple languages
implement "modules" in different ways. JavaScript is the most well known,
but Go also has modules and they are quite different and support versioning
out of the box. In each of these examples there is a requirement that the
programmer write code to import the modules at some place either in the
project (Go) or in every bloody file in the project (JavaScript). PHP
doesn't require this, instead autoloading symbol definitions as they are
encountered.

Any package/module/whatchamacallit system used in PHP needs to build on
this principle, not swim against it, if it is to have any hope of
consideration on the list.

Also, I think the following is important to point out - Composer is NOT a
package manager. It is a dependency manager. There's a subtle difference
between the two.

On my side, I don't care if modules are tightly coupled to namespaces or
not, and if more, that's even why my first idea was to bind a module to
a single-file at first, and making all modules imported from such file
being non-importable-again, thus creating a single module tree that can
be stored at compile-time, have no side-effect at load-time (which is a
big safeguard to avoid other issues), and allowing multiple modules of
seemingly same name to be loaded in the memory at the same time,
similarly to how Node.js allows having different versions of the same
packages to be installed, while also allowing to have one version used
by many modules too.

NPM (not Node, node is the engine not the package/dependency manager) does
this using aliases. PHP doesn't have a way to alias symbols at compile
time. It would be nice if it did - I've suggested it as a parameter to
include not knowing at the time of the suggestion that include isn't a
function, it's a statement, so include "file.php" is the same as
include("file.php"). Setting that aside, PHP projects rarely execute the
include themselves - they let an autoloader handle it, so the autoloader
must know which version to load. This isn't something that even NPM does -
it just aliases and makes both libraries available. The caller still must
specify which library is being pulled in.

Node modules have a single point of entry, defined in the package.json file
but usually index.js. In most Node packages this index.js imports all the
public parts of the package and immediately exports them. Further, an
import in node is an object (as is everything in JavaScript) that
corresponds to that file. Hence

import { foo, bar } from 'MyPackage';

This is using JavaScripts dereference mechanic to pluck members of an
object into the current symbol table. I could go on, but I think it's more
on topic to just say that Node's import/export mechanic, elegant as it
looks, is highly bound to JavaScript's scope rules and how its symbol
table works. These aren't compatible with PHP.

For one, PHP has two symbol tables - one for variables (which is why all
variables start with $ ) and one for everything else. Variables are
affected by function scope, nothing else is. For example, if you define a
function within a function in JavaScript that function will be private to
the function it is defined in - it can't be seen in other scopes. In PHP
the function will be visible on the symbol table.

For another, Node gives each file its own module scope. To move a symbol
from one file to another you should use export and import. This creates a
clear chain of custody for objects and symbols, but by God it also creates
a LOT of boilerplate that the PHP community has no interest in replicating.

Without the chain of custody you rapidly run into trouble. It doesn't
matter if you try to allow the user to put a prefix on the namespace as I
once suggested, or have PHP's engine prefix it automagically somehow - you
still need to correctly disambiguate every blasted reference to that
namespace. This is no easy task - take a look at the code of Strauss -
https://github.com/BrianHenryIE/strauss That project allows you to rewrite
a package with a new namespace, in effect doing it in userland. But as a
precaution it prefixes every single package imported and severs the tie
back to the original packagist. Strauss is used by several WordPress
plugins to make composer library use possible while still remaining
portable between WordPress sites.

The only drawback of having modules like that would be that final
dependency trees in Composer would be non-flat, but again, I think this
non-flat system should be opt-in. Similarly to how flat systems are
opt-in in the Node.js ecosystem (and trust me, I've tried to enforce
"flat" dependencies resolutions in certain Node projects, and it's a
huge hassle). Luckily, the PHP ecosystem is quite fine so far, compared
to Node, and I would definitely keep the "flat" system in Composer for
as long as possible, and make non-flat resolutions only case-specific
(which is rare, and usually framework-dependent, like with Wordpress
plugins for instance).

I don't think it's a reasonable ask of Composer or any other dependency
manager to try to resolve this without having a clear binding map like the
one JavaScript forces you to create by how its module system works.

I still hope we could have a grouped discussion on this.

Larry's Modules proposal (here:
https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md )

is IMO a very good starting point, and it only lacks the "multiple
modules with different versions". And module definition with an INI file
looks interesting.

Adding a "container" system when importing a module can maybe allow
this, I don't know...?

@Michael: do you think you could start a new thread for PHP containers?
Do you already have some research that you could bring for a pre-RFC
discussion?

This is the Container thread - I changed the subject line on my previous
reply although I did include (was: ) so that people could track I was
forking.

I don't have much to add beyond my previous post. I haven't heard from
anyone with engine experience about the feasibility or difficulty of what I
propose. To review (for anyone just joining but missing the previous
message)

The user signals to the engine they want to include a php file AND
process it independent of the current execution environment. No shared user
defined symbols or variables.
That file returns an interface so that the calling thread can talk to
the child.
As the processes reside on different threads these calls will need to be
asynchronous to be optimal, otherwise the caller will be in a blocked state
while the child executes the called method. It can work without the PHP
Async / Await RFC's conclusion, but it won't be in ideal form without it.

Containers provide process isolation. Say I have a WordPress plugin that I
want to use composer libraries with. Say, Guzzle. I can write my own
container interface without touching Guzzle's code exposing the parts of
Guzzle I need for my plugin. Since WordPress has no current core composer
support I would need to carry a loader in my distro to be ran on the
install hook of the plugin, bringing in composer and letting it in turn
pull the libraries that I need to use. If someone later writes a plugin
that uses an incompatible version of Guzzle that doesn't matter - even if
they lazily load it into the main symbol table by not using a container.
My plugin is isolated.

That isolation comes at a price. Each plugin has an independent vendor
directory with no way to resolve complete redundancy. At least not in
WordPress, which has no current composer implementation in core (I'm on the
wp trac in a thread discussing it though).

There are open questions though that must be answered before this container
idea is seriously explored. Most critical, can PHP be made to handle an
object passing from one thread to another? That is, continuing from the
example above, can a client instance from one GuzzleContainer coexist on
the main thread with a client instance from a different container and
referencing different code? Or will methods be unable to cross the barrier?
What are the implications for the Reflection API and using it to examine an
object that originated from another process thread referencing symbols that
don't exist on the current thread?

The idea of containers is simple to state - but the implications are
profound and might be unworkable. I simply don't know enough about the PHP
engine to know.

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

Tue, 16 Jun 2026 04:20:31 +0000

Am 15.06.2026 um 10:43 schrieb Kamil Tekiela tekiela246@gmail.com:

Hi internals,

Following the pre-RFC discussion from late May [1], I'm moving the
"pure-code source files" proposal into formal RFC stage as

https://wiki.php.net/rfc/optional_php_tags

The mechanism is a single new opt-in file extension, .phpc, whose
semantics are: the file is parsed as pure PHP. The lexer enters
ST_IN_SCRIPTING on the first byte; no opening <?php is required.
A leading UTF-8 BOM and a CLI shebang are silently skipped. The
classic .php extension and every other code-loading path are
completely untouched - the change is strictly additive.

Reference implementation: PR against php/php-src (link in the RFC).
Patch is ~50 lines of straight-line C in
Zend/zend_language_scanner.l::open_file_for_scanning, plus 15 new
.phpt tests in Zend/tests/phpc/. Full regression run against Zend/,
ext/tokenizer/, ext/standard/, ext/spl/, ext/reflection/, ext/phar/
(9836 tests): 0 failures, 0 modifications to any pre-existing test.

Pre-RFC feedback, addressed in the RFC document:

Ben Ramsey on engine-vs-SAPI dispatch:
own section explaining why include/require/Phar all live below
SAPI and need engine-level handling. Ben's -p/stdin idea is
adopted as Future Scope (a sister RFC after this one).

Alex Rock on alternatives (env var, include_pure keyword,
declare(pure=1)): each rebutted individually under "Rejected
Alternatives".

Bruce Weirdan on BC of the .phpc extension itself: own
paragraph in the BC section, honest about the fact that I have
NOT scanned public corpora; asking voters with private-codebase
visibility for data points during Discussion.

.pyc visual collision and scattered prior .phpc usage:
addressed via a sub-vote on the extension name (.phpc / .phpp /
.pcode / .phpx).

Security (source-code exposure via misconfigured webservers,
the historic .inc footgun): own section with mandatory
documentation commitments and canonical Apache/Nginx/Caddy/
FrankenPHP snippets in Appendix A.

Boutell 2012 and Ohgaki 2014: own section distinguishing this
proposal mechanically from both.

Discussion period: at least two weeks from today. Looking forward
to feedback, especially on:

The Open Issues block in the RFC (extension name, real-world
.phpc-in-use data, case-sensitivity on Windows/macOS).

Anything in the Phar / OPcache surface I should test more
thoroughly before voting opens.

Whether the Security section's commitments are strong enough.

Thanks for reading,
Hendrik Mennen

[1] https://news-web.php.net/php.internals/131024

I tried to catch up on this discussion last night. I see a lot of things that could go wrong with this, but I don't see a clear motivation for why would we want this change.

Reduced ceremony in pure-code files.
This is a moot point because after the change you still have the ceremony of adding .phpc to every file. Just unnecessary churn.

First-class CLI scripts.
Is this really a big concern? Is it going to work better? Are there things you cannot do today because of it?

Clearer file-mode intent.
We already have that. By convention many people add .php extension to pure PHP files, and .phtml to templates. It's not mandated by a language and people are free to choose their naming conventions.

Strictly additive.
That's not entirely true, but that's beside the point. Why is this one of the main motivations? We don't add things just because we can. They need to have a purpose.

We already have a good way of writing pure PHP code files. Just add 5 characters at the beginning of the file <?php and the rest of the file will be treated as PHP source code.

I would also like to echo what others said that PHP source code doesn't have to be within <?php. A text file will be compiled and interpreted by PHP as a print statement. Even in pure PHP code files you may want to escape the PHP context with ?>. Mandating that a file with a certain extension will have these restrictions is worse than having to start every file with <?PHP.

Regards,
Kamil

Hi Kamil,

Thanks for the substantive pushback - these are exactly the right
questions, and you're correct on more of them than the RFC as currently
worded admits.

Conceding upfront: "strictly additive" is a necessary property, not a
motivation. I leaned on it too much. Same for the three weaker arguments
(CLI ergonomics, convention clarity, ceremony shift) - none of them
alone justifies the mechanism.

The honest single-sentence motivation:

Most new PHP files written today are pure code (framework classes,
autoloaders, console commands, configuration). For those files the
<?php opener carries zero semantic information. PHP is the only
modern mainstream language where it is mandatory.

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:

The friction is real and a small targeted addition is worth
shipping. (what the RFC proposes)
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, ...)
The friction is not real, or not worth a language change at all.

That is a sharper question than re-litigating each motivation in turn,
and the answer determines whether to refine, pivot, or withdraw before
voting.

On your last point - that .phpc "restricts" PHP's text-as-print
feature - I think we agree more than disagree. .phpc would not change
.php behaviour at all. It is opt-in by filename. Authors who want the
templating shape keep using .php, ?> drop-out continues to work inside
.phpc, and the engine on existing files is byte-for-byte identical.
The "restriction" you describe (no top-of-file inline content;
<?php-as-tag rejected inside .phpc) is intentional - it is what makes
the mode meaningful for the cases that opt in.

I will update the RFC's Motivation section to reflect this
clarification in the next day or two so the rest of the Discussion
runs on the stronger framing rather than the weaker one I shipped
with.

Thanks again,
Hendrik

[RFC] Working Groups

Tue, 16 Jun 2026 02:02:57 +0000

2026年6月16日(火) 1:02 Larry Garfield larry@garfieldtech.com:

Anything that doesn't need special powers can more efficiently be organized without the overhead of the initial RFC, as can also be seen by The PHP Foundation planning to launch 6 “special interest groups” in the remainder of 2026 without needing to involve the PHP project:

https://thephp.foundation/blog/2026/06/11/integrating-community- feedback-into-foundation-strategy-part2/#community-special-interest-groups

I'm aware of the PHP Foundation special interest groups, and Elizabeth and I discussed them before I opened the Working Groups RFC for discussion. We agreed they do not cover the same ground as the Working Groups RFC. By design, the PHP Foundation SIGs have no operational or governance authority over the PHP Project. There can be cross-pollination and collaboration between the initiatives, but the SIGs are external, community-focused, interest groups, while PHP WGs are internal, PHP Project-focused, operational groups.

My 2cents in the form of questions (because I might have missed something):

Since the PHPF's role is to support, help and discuss, then shouldn't
PHPF operatives be excluded from voting on RFCs, whatever the involved
WG? It would ensure that the PHP voters (aka "The community that
includes contributors and core team members") can take decisions
without the PHPF being able to intervene if there's a disagreement
between the two groups, I guess...?

"PHPF operatives" sounds very negative. Bear in mind, the Foundation currently employs a majority of the people who really understand the PHP engine and how to maintain it. Excluding them from voting would be.. project suicide.

The Foundation has no vote. The people who do half the work for PHP, who happen to work for the Foundation, have votes. As they should.

And similarly, shouldn't there be a mandatory consultation from the PHP
community when the PHPF actually operates on something that impacts the
community on non-RFC-mandatory-operations, like marketing,
communication, etc.? I mean, if at some point the PHPF communicates on
the web on something the PHP community would disagree with (concluded
via a vote of whatever sort), shouldn't the PHPF, as a "consultative
agency", have to update their acts and productions to fit to the
community's views? (that would solve parts of the issues with the
recent hot discussions on a certain link to a certain platform on PHP's
website, for example).

All these questions are here because PHP has no official governance
other than the (sometimes vaguely) designated "PHP Community", and the
PHPF's role, from what I understand, is mostly to help the community
to decide and act on PHP-related tasks, but not directly decide nor
act.

I might be off of some details, so feel free to correct me if I miss
something, if I'm mistaking, or if I misunderstand certain roles or
notions.

From the Foundation's home page:
The PHP Foundation is a collective of people and organizations relying on the PHP language. Its mission is to ensure the long-term prosperity of the PHP language.

The PHP Foundation focuses on providing financial support and guidance to PHP language developers to support its goals of improving the language for its users, providing high-quality maintenance, and improving the PHP language project to retain current contributors and to integrate new contributors.

The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors.

Read our announcement for more details.
That's what the Foundation does and is for.

It really seems like you're inventing problems that do not exist, and have no bearing on the project itself creating working groups. That those WGs may overlap with the Foundation, both in goal and personnel, is a good thing in my mind.

--Larry Garfield

Hi Ben and Internals

I agree this proposal. I'm glad that if this proposal is accepted.

Please let me story that join in the php-src repo and this mailing list.
So I spend many time (3-4 years?) because I don't know how to join
this community.
Therefore, Working groups can easy to access to this community from the world.

I hope that people from all over the world who are interested will come.

Regards
Yuya

Yuya Hamada (tekimen)

[RFC] [Discussion] Literal Scalar Types

Tue, 16 Jun 2026 00:44:32 +0000

On Tue, Jun 16, 2026, 1:31 AM Sarina Corrigan sarina.corrigan@gmail.com
wrote:

On Mon, Jun 15, 2026, 20:05 Seifeddine Gmati azjezz@carthage.software
wrote:

While this RFC works alongside the pattern matching proposal by Larry and
Ilija, neither requires the other. The two are unrelated for several
reasons.

So to answer your question, no, I am not looking for pattern matching. I
see these as two distinct features that address different needs within the
language.

I don't believe they are addressing entirely different needs. I believe
the feature that static analysis tools support is pattern matching more
than it is typing. The question for me becomes whether patterns be
represented through types, or whether they should be matched against values.

Strictly denoting types and validating patterns are two separate concerns.
One asks "What can I do with this?" while the other asks "Is this within
expected bounds?". I am personally not against validating patterns within
type declarations, as is supported in Typescript, Scala (I believe), and to
an extent PHP with false|true. But I do believe they are different concerns.

I also think that, this being a form of pattern matching, if approved
would set a direction for the pattern matching RFC to treat patterns more
closely as types than assertions and guards (as their RFC currently
proposes). I am again not saying this is a bad thing, but it is worth
acknowledging.

Hi Sarina,

I don't think we disagree here. I already said above that I think pattern
matching should match against types with variable binding; this actually
makes pattern matching easier because to expand it, you just have to expand
the type system, and patterns get expanded for free.

However, I think this is a discussion for the pattern matching RFC, not for
the literal types RFC.

Cheers,
Seifeddine.

[RFC] [Discussion] Literal Scalar Types

Tue, 16 Jun 2026 00:31:44 +0000

On Mon, Jun 15, 2026, 20:05 Seifeddine Gmati azjezz@carthage.software
wrote:

While this RFC works alongside the pattern matching proposal by Larry and
Ilija, neither requires the other. The two are unrelated for several
reasons.

So to answer your question, no, I am not looking for pattern matching. I
see these as two distinct features that address different needs within the
language.

I don't believe they are addressing entirely different needs. I believe the
feature that static analysis tools support is pattern matching more than it
is typing. The question for me becomes whether patterns be represented
through types, or whether they should be matched against values.

Strictly denoting types and validating patterns are two separate concerns.
One asks "What can I do with this?" while the other asks "Is this within
expected bounds?". I am personally not against validating patterns within
type declarations, as is supported in Typescript, Scala (I believe), and to
an extent PHP with false|true. But I do believe they are different concerns.

I also think that, this being a form of pattern matching, if approved would
set a direction for the pattern matching RFC to treat patterns more closely
as types than assertions and guards (as their RFC currently proposes). I am
again not saying this is a bad thing, but it is worth acknowledging.

[RFC] [Discussion] Literal Scalar Types

Tue, 16 Jun 2026 00:02:36 +0000

Hey Seifeddine,

Am 15.06.2026 um 03:22 schrieb Seifeddine Gmati <azjezz@carthage.software
:

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

I think you are solving the wrong (or rather: only a specific subset of
the) problem. What you actually probably want is pattern support in type
positions. Let me know if I'm wrong in my assumption here.

I.e. basically support expressions as specified by
https://wiki.php.net/rfc/pattern-matching in property and function
argument/return positions. Which does this, and ranges and everything else
you'd need.

Which is a worthwhile addition, but we should first get pattern-matching
done, then we can do one RFC broadening the applicability of patterns.

Bob

Hi Bob,

My interest is not pattern matching; my focus is on the type system and
expanding it to be more expressive. My main motivation is that static
analysis tools (like PHPStan, Psalm, and Mago) already do many things that
PHP itself cannot, and I believe those features belong in the engine.
Literal types serve as a fundamental building block for future type system
features such as array shapes, tuples, and potentially even conditional
types.

While this RFC works alongside the pattern matching proposal by Larry and
Ilija, neither requires the other. The two are unrelated for several
reasons.

So to answer your question, no, I am not looking for pattern matching. I
see these as two distinct features that address different needs within the
language.

Cheers,
Seifeddine.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 22:59:53 +0000

Hey Seifeddine,

Am 15.06.2026 um 03:22 schrieb Seifeddine Gmati azjezz@carthage.software:

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

I think you are solving the wrong (or rather: only a specific subset of the) problem. What you actually probably want is pattern support in type positions. Let me know if I'm wrong in my assumption here.

I.e. basically support expressions as specified by https://wiki.php.net/rfc/pattern-matching in property and function argument/return positions. Which does this, and ranges and everything else you'd need.

Which is a worthwhile addition, but we should first get pattern-matching done, then we can do one RFC broadening the applicability of patterns.

Bob

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 22:37:23 +0000

Hi

For what it is worth, I am personally fine with tenths(0.1 + 0.2)
failing to match 0.3. This is not new behaviour: 0.1 + 0.2 == 0.3
is already false, and a match (0.1 + 0.2) already skips a 0.3 arm
for exactly the same reason. So a literal float type behaves
consistently with comparison and match, rather than introducing a
new surprise.

Yes, it is consistent with the existing behavior, but I don't think that
this makes it any less confusing. And for this specific proposal, adding
support for floats would be a deliberate decision rather than just
something that naturally follows from “existing === semantics” as with
match() which works on two values rather than values + types.

On your concrete questions: 4e3 is a valid float literal and works
today; it normalizes to 4000.0 (the type also stringifies as
4000.0). NAN and INF, on the other hand, are not literals but
constant identifiers that go through constant resolution. They are out
of scope for the same reason FOO is above: NAN $foo could just as
well mean a class named NAN.

Yes, I'm aware (based on a look at the implementation). This was
intended to be a subtle note that this is not explicitly spelled out in
the RFC.

The RFC text should comprehensively explain the behavior all possible
edge cases and ambiguities so that folks can form an educated opinion
based on the RFC text alone without needing to be able to understand the
implementation.

Writing that out, I also notice that the “Ecosystem” sub-section is
missing from the “RFC Impact” section (and the “To Existing Extensions
” sub-subsection would probably also be useful to know) and the voting
widget is also missing.

Best regards
Tim Düsterhus

Hi Tim,

That is fair. Float support should be a deliberate choice rather than
something that rides in on existing === semantics; the match
analogy only goes so far, since match compares two values whereas
this compares a value against a type.

You are also right that the RFC text has to stand on its own. I will
expand it to spell out the edge cases explicitly, including:

Which numeric forms are accepted and how they normalize.
Hexadecimal, octal, binary and underscore-separated integer literals
(0x1A, 0o17, 0b101, 1_000) all canonicalize to their value,
and 4e3 is a valid float literal normalizing to 4000.0.
That NAN and INF are constants, not literals, and so are not
accepted, for the same reason a bare FOO is not.
String literal handling: single versus double quotes, escape
resolution, and the rejection of interpolation.

I will also add the missing "Ecosystem" and "To Existing Extensions"
subsections under "RFC Impact", and the voting widget.

On voting: rather than a single yes/no, would it make sense to split
it so each decision can stand on its own?

Add support for literal string types. (2/3)
Add support for literal integer types. (2/3)
Add support for literal float types. (2/3)
Coercion behaviour: coerce to the base type before checking
membership (as the RFC currently describes), or always require an
identity match. (1/2)

The last one is worth surfacing in particular. true, false and
null do not coerce at all today, even in coercive mode: passing 1
to a true parameter is a TypeError, not a coercion to true. If
we want literal scalars to be consistent with the existing value
types, an identity match is arguably the more natural behaviour, so I
would rather put it to the list than bake it in.

Best regards,
Seifeddine

[RFC] [Discussion] Query Parameter Manipulation Support

Mon, 15 Jun 2026 20:36:47 +0000

Hi Tim,

First of all, thanks for your detailed explanation!

Does that make sense?

Sure, this is a very sensible approach, similar to the algorithms I have
also considered myself before. The reason why I
started to search for alternatives is because lookups are inefficient this
way: all get*() methods have an O(n) time complexity
by default, while currently, looking up keys in $_GET is O(1). This
regression is what I tried to avoid with storing query params
along with an array key.

However, I realized in the meanwhile that it may be possible to eliminate
much of the performance overhead by using two hash tables:
one for exact search (WHATWG URL-alike API), and one for searching the
prefixes before the [] pair (for the array API). I haven't
tried this idea out yet in practice, so I'll need to do some POC first
before continuing with the RFC.

Regards,
Máté

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 20:32:53 +0000

For what it is worth, I am personally fine with tenths(0.1 + 0.2)
failing to match 0.3. This is not new behaviour: 0.1 + 0.2 == 0.3
is already false, and a match (0.1 + 0.2) already skips a 0.3 arm
for exactly the same reason. So a literal float type behaves
consistently with comparison and match, rather than introducing a
new surprise.

Yes, it is consistent with the existing behavior, but I don't think that
this makes it any less confusing. And for this specific proposal, adding
support for floats would be a deliberate decision rather than just
something that naturally follows from “existing === semantics” as with
match() which works on two values rather than values + types.

On your concrete questions: 4e3 is a valid float literal and works
today; it normalizes to 4000.0 (the type also stringifies as
4000.0). NAN and INF, on the other hand, are not literals but
constant identifiers that go through constant resolution. They are out
of scope for the same reason FOO is above: NAN $foo could just as
well mean a class named NAN.

Yes, I'm aware (based on a look at the implementation). This was
intended to be a subtle note that this is not explicitly spelled out in
the RFC.

The RFC text should comprehensively explain the behavior all possible
edge cases and ambiguities so that folks can form an educated opinion
based on the RFC text alone without needing to be able to understand the
implementation.

Writing that out, I also notice that the “Ecosystem” sub-section is
missing from the “RFC Impact” section (and the “To Existing Extensions
” sub-subsection would probably also be useful to know) and the voting
widget is also missing.

Best regards
Tim Düsterhus

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 20:11:16 +0000

Hi Tim,

I think I might agree here, and others have raised the same concern on
Discord. Dropping float literals for now simplifies the RFC, so I am
inclined to do that, though I would like to hear what others think
before removing them.

We debated allowing float as a backing type for enums, and eventually decided against it for a similar reason: It's not stable or discrete enough to be useful, and no other language we looked at supported them.

I'm still undecided on the RFC as a whole (I need to fully read it first), but would support limiting the literals to just int and string.

--Larry Garfield

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 19:49:04 +0000

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at 17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):

But this is tangential to my main point: if we accept that we are
moving towards fully reified generics, and this is only a stepping
stone, and we document this widely and educate about it, then in
future versions we can tighten from "bounds erased" to "fully
reified." Yes, there will still be breakages, but far, far fewer
breakages. This should be tolerable.

I don't want this RFC to be our final form: I only want it to be a
stepping stone.

I concur. My concern is, as Rob pointed out, it may not be possible to add enforced generics on top without API changes. Not just "your code was already broken and now we're telling you" changes, but changing the way catch blocks behave. I'm not sure if we're OK with that level of breakage if we incrementally add more enforcement.

Is that concern valid? I'm not sure. We didn't get a chance to flesh it out before the vote was called.

--Larry Garfield

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 19:49:06 +0000

Hi

describing APIs that already exist. array_filter's $mode really
accepts 0|1|2, but it's typed int because that's all the type
system can say today. we can't retype it as an enum without breaking
every caller. a literal union lets the signature state the actual
contract.

We can retype this kind of API with enums.

See the “Correctly name the rounding mode and make it an Enum” RFC
(https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum)
for an example: We first widen the parameter to accept the enum so that
folks can opt-in to the new API. At a later point we alias the constants
to the corresponding enum cases and deprecate passing the integers and
then we remove the support for the integers (and constants).

Using literal types is going to result in a terrible user-experience,
because the signature does not provide any hint as to which constants
are supposed to be used with the API which means that the resulting
error message is also useless to the user. Enums - or the existing
manual validation - is much preferable here.

ad-hoc / open value sets. for a library, "ascii"|"utf-8" would need
its own named symbol ( enum BorderStyle { case Ascii; case Utf8 }, a
new file, an import ) for what is really two strings. and because an
enum is a closed set, adding a third style later breaks any consumer
that match-es over it without a default. widening the union on a
parameter ( "ascii"|"utf-8"|"unicode" ) is contravariant, so it breaks
nobody.

The existing \RoundingMode enum is already intended to be a
non-exhaustive (parameter-only) enum where users are expected to include
a default case in case new values are being added.

I have a very rough draft in
https://wiki.php.net/rfc/non_exhaustive_marker to make this type of
contract more explicit.

Having an “own named symbol” for the allowed values is a benefit to me,
because this makes it easy to reuse the list of allowed values in
different locations without needing to resort to copy and paste, for
example in decorators that just pass through the values without touching
them.

scalar interop. a literal value is the scalar, so it works as an
array key, compares with ===, round-trips through json, etc. enum
cases are objects and don't.

Enums can be compared with ===.

Best regards
Tim Düsterhus

Fair points. I will happily concede that for the internal flag-style
APIs (rounding mode, array_filter, and so on) the enum migration
path you describe is a good fit, and the reuse you get from a named
symbol is a real benefit. I do not think literal types are the right
tool for everything enums cover.

On the === point specifically: enums compare with === to other
enum cases, but not to the scalar values they stand for.
Status::Success === 'success' is always false. So the moment your
data is actually a scalar, a string from json_decode, a value in an
associative array, a column from the database, the enum case is no
longer interchangeable with it; you have to map back and forth with
->value and ::from().

That is the case literal types are really aimed at, and it is clearest
with array shapes (which I have started working on and would put in
future scope). Consider typing a decoded JSON response:

public abstract function getResponse(): ['status' => 'success' |
'error', 'message' => null | string, 'data' => null | array, ...];

The values here are genuinely scalars on the wire. A status field
that is "success" or "error" is a discriminated union you can type
exactly, and it round-trips through json_encode / json_decode
untouched. This is everywhere in practice: tagged event payloads
({"type": "created" | "updated" | "deleted"}), result envelopes
({"ok": true, ...} vs {"ok": false, "error": string}), open/closed
flags, mode strings. Modelling these with enums means converting every
field on the way in and on the way out, even though the data never
stops being a plain string.

So I see them covering different ground: enums for named, reusable,
behaviour-carrying sets; literal types for describing scalar data that
already exists in its raw form, particularly structured payloads like
JSON.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 19:45:25 +0000

Hi

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

I have given the RFC a quick first review pass and would suggest to
leave out support for float literals. From a conceptual perspective
floats are much closer to being continuous values than they are to
discrete values and picking individual values from a continuous range is
typically not all that useful.

Support for floats is also going to invite the usual confusion about
implicit rounding:
 function tenths(
     0.0|0.1|0.2|0.3|0.4|0.5|0.6|0.7|0.8|0.9 $tenth
 ): void { var_dump($tenth); }
where tenths(0.1 + 0.2) will result in a TypeError. The RFC is also
unclear what values are valid floating point literals. As an example, is
4e3 a valid float literal? Is NAN a valid float literal?

Best regards
Tim Düsterhus

Hi Tim,

I think I might agree here, and others have raised the same concern on
Discord. Dropping float literals for now simplifies the RFC, so I am
inclined to do that, though I would like to hear what others think
before removing them.

For what it is worth, I am personally fine with tenths(0.1 + 0.2)
failing to match 0.3. This is not new behaviour: 0.1 + 0.2 == 0.3
is already false, and a match (0.1 + 0.2) already skips a 0.3 arm
for exactly the same reason. So a literal float type behaves
consistently with comparison and match, rather than introducing a
new surprise.

On your concrete questions: 4e3 is a valid float literal and works
today; it normalizes to 4000.0 (the type also stringifies as
4000.0). NAN and INF, on the other hand, are not literals but
constant identifiers that go through constant resolution. They are out
of scope for the same reason FOO is above: NAN $foo could just as
well mean a class named NAN.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 19:42:54 +0000

Den 15. jun. 2026 kl. 19.23 skrev Sarina Corrigan sarina.corrigan@gmail.com:

It may be worth mentioning that within the Pattern Matching RFC future scope, and mentioned a couple times within the discussion thread for the RFC, there is a similar proposal that would allow for this without using specific literal types.

It's outlined in https://github.com/Crell/php-rfcs/blob/master/pattern-matching/future.md under "Parameter or return guards"

It would allow for:
function setLogLevel (string $level is 'debug' | 'info' | 'warning' | 'error'): void {}
Of course, I don't think that a potential future scope of an in-draft RFC is reason to dismiss a more direct implementation of literal scalar types, but it may be useful to compare other ways we could achieve the same functionality. I personally find pattern matching within parameter/return types more versatile while keeping direct typing system more simplified. Specifically for a range feature that Ben Ramsey brought up, pattern matching for parameters seems much more appropriate.

All that being said, I would gladly welcome literal scalar types.

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

Hi,
This sounds very promising. But I would be confused about receiving a TypeError when just the value of the parameter is wrong.

As described in the RFC if I send 4 to a parameter that could only be 1, 2 or 3. I would expect a TypeError if I sent “abc” ?

Kind regards
Lars Nielsen

Hi Lars,

I think the confusion comes from treating "type" and "value" as two
separate things, which is the usual mental model. Literal scalar types
deliberately blur that line: each value is itself a type, a unit type
containing exactly one value.

So 1|2|3 is not "an int that happens to be restricted", it is the
union of three unit types 1, 2 and 3. Under that view, both 4
and "abc" fail for the same reason: neither is a member of the
declared type. There is no separate "the value is wrong" category, it
is all type membership, so a TypeError is the consistent outcome.

It is the same thing that already happens with the true type today:
passing false to a true parameter is a TypeError, even though
both are booleans.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 19:41:36 +0000

On Mon, 15 Jun 2026 at 18:20, Sarina Corrigan sarina.corrigan@gmail.com
wrote:

It may be worth mentioning that within the Pattern Matching RFC future
scope, and mentioned a couple times within the discussion thread for the
RFC, there is a similar proposal that would allow for this without using
specific literal types.

It's outlined in
https://github.com/Crell/php-rfcs/blob/master/pattern-matching/future.md
under "Parameter or return guards"

It would allow for:
function setLogLevel (string $level is 'debug' | 'info' | 'warning' |

'error'): void {}


Of course, I don't think that a potential future scope of an in-draft RFC

is reason to dismiss a more direct implementation of literal scalar types,
but it may be useful to compare other ways we could achieve the same
functionality. I personally find pattern matching within parameter/return
types more versatile while keeping direct typing system more simplified.
Specifically for a range feature that Ben Ramsey brought up, pattern
matching for parameters seems much more appropriate.

All that being said, I would gladly welcome literal scalar types.

On Sun, Jun 14, 2026, 21:24 Seifeddine Gmati azjezz@carthage.software
wrote:

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

Hi Sarina,

Thanks for the pointer, that is a good read.

I don't think literal scalar types conflict with the pattern matching
future scope at all. The way I see it, a pattern is, or at least should be,
a type. $foo is Foo { x: 10 } is really asking "does $foo have the type
Foo with x equal to 10", and I would happily see us later allow Foo { x: 10 } as a type on its own. The one thing a pattern adds over a type
is binding: capturing a value in place of a sub-type, e.g.

if ($foo is Foo { x: $x }) { /* $x is bound here */ }

which a plain type declaration cannot do.

On the specific syntax in that document:

function setLogLevel(string $level is 'debug' | 'info' | 'warning' |
'error'): void {}

reads as redundant to me. The string contributes nothing once the value
set is given, so with literal scalar types the same intent is simply:

function setLogLevel('debug' | 'info' | 'warning' | 'error' $level): void {}

So I see the two as complementary rather than competing: literal types
provide the value-as-type building block, and pattern matching can build on
top of it for binding and destructuring.

Glad to hear you would welcome the feature.

Cheers,
Seifeddine

[RFC] [Discussion] Serializable closures from constant expressions

Mon, 15 Jun 2026 19:30:18 +0000

I'd like to open the discussion on a new RFC:
https://wiki.php.net/rfc/serializable_closures

Don't forget to link the discussion thread in the RFC. For your
convenience: https://news-web.php.net/php.internals/131198

As to the RFC itself: I think it might be useful to split this into two
RFCs, similarly to how Volker and I split the initial support for
Closures in const-expr into support for Closures and support for first
class callables.

Specifically I believe that the proposed serialization format is fragile
and the stated security model, which I suspect heavily influenced the
design of the serialization format, is probably overly cautious.

I don't think it is a problem to make unserialize() a Closure factory,
because the created Closure is “inert”. Contrary to arbitrary object
unserialization (which will immediately call the deserialization hooks
and then later __destruct()), the Closure will not actually do anything
unless it is called.

If folks are able to unserialize arbitrary payloads - which is
documented to be unsafe - they already have capabilities that are much
more powerful than “creating Closures”.

For first class callables specifically, there is a very obvious and
stable identifier to use: The underlying function name.

For regular Closures, I don't like how changing something unrelated
(namely adding new Closures to a class) can change the meaning of the
serialized data. This is not how serialization works right now: The
value in question is in full control of its serialization format and is
able to “gracefully” support existing serialized payloads using an old
format within an unserialization hook (e.g. by including a version
number field). This allows to e.g. keep serialized queue jobs working
across deploys.

As for the var_export() in the future scope: I think adding support for
first class callables to var_export() would be a change that can just
be done without an RFC. It might be a good first step that might already
be helpful to your use case?

Best regards
Tim Düsterhus

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 19:21:45 +0000

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at 17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):
class Option<+A>
{
 // B >: A means B is an ancestor of A
 // Since all As are Bs, you can return the A here
 function get_or_default: A>(Option $option, B $default): B
 {
 return $option->has_some()
 ? $option->get()
 : $default;
 }
 // todo: the rest of the implementation
}
You can't take A $default and return A because this violates the
variance laws: a covariant type A cannot be used in parameter
position. So alternatively you could solve this with inout A $default or similar.

Presumably this would work with the current proposal:
class Option<+A> {
 public function getOrDefault(B $default): A|B {
 return $this->hasSome() ? $this->get() : $default;
 }
}

The version with a lower bound says it returns an A or an ancestor of A.
The version with the union type says it returns an A or a B, and
there's no relation between A and B at all.

They both allow correct code: you can correctly return an A or
ancestor of A in either one. Only the version with the lower bound
rejects incorrect code, though, and that's an important duty.

But this is tangential to my main point: if we accept that we are
moving towards fully reified generics, and this is only a stepping
stone, and we document this widely and educate about it, then in
future versions we can tighten from "bounds erased" to "fully
reified." Yes, there will still be breakages, but far, far fewer
breakages. This should be tolerable.

I don't want this RFC to be our final form: I only want it to be a
stepping stone.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 18:55:23 +0000

describing APIs that already exist. array_filter's $mode really
accepts 0|1|2, but it's typed int because that's all the type
system can say today. we can't retype it as an enum without breaking
every caller. a literal union lets the signature state the actual
contract.

We can retype this kind of API with enums.

See the “Correctly name the rounding mode and make it an Enum” RFC
(https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum)
for an example: We first widen the parameter to accept the enum so that
folks can opt-in to the new API. At a later point we alias the constants
to the corresponding enum cases and deprecate passing the integers and
then we remove the support for the integers (and constants).

Using literal types is going to result in a terrible user-experience,
because the signature does not provide any hint as to which constants
are supposed to be used with the API which means that the resulting
error message is also useless to the user. Enums - or the existing
manual validation - is much preferable here.

ad-hoc / open value sets. for a library, "ascii"|"utf-8" would need
its own named symbol ( enum BorderStyle { case Ascii; case Utf8 }, a
new file, an import ) for what is really two strings. and because an
enum is a closed set, adding a third style later breaks any consumer
that match-es over it without a default. widening the union on a
parameter ( "ascii"|"utf-8"|"unicode" ) is contravariant, so it breaks
nobody.

The existing \RoundingMode enum is already intended to be a
non-exhaustive (parameter-only) enum where users are expected to include
a default case in case new values are being added.

I have a very rough draft in
https://wiki.php.net/rfc/non_exhaustive_marker to make this type of
contract more explicit.

Having an “own named symbol” for the allowed values is a benefit to me,
because this makes it easy to reuse the list of allowed values in
different locations without needing to resort to copy and paste, for
example in decorators that just pass through the values without touching
them.

scalar interop. a literal value is the scalar, so it works as an
array key, compares with ===, round-trips through json, etc. enum
cases are objects and don't.

Enums can be compared with ===.

Best regards
Tim Düsterhus

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 18:43:14 +0000

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

I have given the RFC a quick first review pass and would suggest to
leave out support for float literals. From a conceptual perspective
floats are much closer to being continuous values than they are to
discrete values and picking individual values from a continuous range is
typically not all that useful.

Support for floats is also going to invite the usual confusion about
implicit rounding:

 function tenths(
     0.0|0.1|0.2|0.3|0.4|0.5|0.6|0.7|0.8|0.9 $tenth
 ): void { var_dump($tenth); }

where tenths(0.1 + 0.2) will result in a TypeError. The RFC is also
unclear what values are valid floating point literals. As an example, is
4e3 a valid float literal? Is NAN a valid float literal?

Best regards
Tim Düsterhus

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 18:31:57 +0000

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at 17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):
class Option<+A>
{
 // B >: A means B is an ancestor of A
 // Since all As are Bs, you can return the A here
 function get_or_default: A>(Option $option, B $default): B
 {
 return $option->has_some()
 ? $option->get()
 : $default;
 }
 // todo: the rest of the implementation
}
You can't take A $default and return A because this violates the
variance laws: a covariant type A cannot be used in parameter
position. So alternatively you could solve this with inout A $default or similar.
Presumably this would work with the current proposal:
class Option<+A> {
 public function getOrDefault(B $default): A|B {
 return $this->hasSome() ? $this->get() : $default;
 }
}
Hack also has super type constraints: https://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constraints
It wouldn’t actually do anything though…

— Rob

Sorry. Sent before I was finished writing.

It wouldn’t actually do anything though…

Both are “correct” in erased generics. You’d receive no error or feedback what you’d written was “wrong” or “broken”. In both examples, types reduce to mixed.

— Rob

[VOTE] Deprecate returning values from construct() and destruct()

Mon, 15 Jun 2026 18:31:34 +0000

Tim, sorry if I missed it in the discussion and RFC: is there any plan
to allow declaring function __construct(): void at the same time?
Since:

We are going to actively enforce that they don't return anything,

and returning void is the correct declaration for such functions
(and I would argue null as well but I don't care too much about
this, I debated mentioning it at all because it's a bit off in the
weeds),

doesn't it make sense to also allow declaring a void return at the same time?

Allowing an explicit : void return is not part of the RFC.

I intentionally focused on the deprecation to keep the RFC focused on
the “important bits”, namely removing this confusing behavior.

That's also why __clone() is intentionally left to future scope, since
the situation there is slightly different. It definitely makes sense to
me to align __clone() with __construct() in one way or another,
though, since they effectively only differ in s/new/clone/ for their
intended use.

Best regards
Tim Düsterhus

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 18:27:14 +0000

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at 17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):
class Option<+A>
{
 // B >: A means B is an ancestor of A
 // Since all As are Bs, you can return the A here
 function get_or_default: A>(Option $option, B $default): B
 {
 return $option->has_some()
 ? $option->get()
 : $default;
 }
 // todo: the rest of the implementation
}
You can't take A $default and return A because this violates the
variance laws: a covariant type A cannot be used in parameter
position. So alternatively you could solve this with inout A $default or similar.
Presumably this would work with the current proposal:
class Option<+A> {
 public function getOrDefault(B $default): A|B {
 return $this->hasSome() ? $this->get() : $default;
 }
}
Hack also has super type constraints: https://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constraints

It wouldn’t actually do anything though…

— Rob

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 18:25:04 +0000

Den 15. jun. 2026 kl. 19.23 skrev Sarina Corrigan sarina.corrigan@gmail.com:

It may be worth mentioning that within the Pattern Matching RFC future scope, and mentioned a couple times within the discussion thread for the RFC, there is a similar proposal that would allow for this without using specific literal types.

It's outlined in https://github.com/Crell/php-rfcs/blob/master/pattern-matching/future.md under "Parameter or return guards"

It would allow for:
function setLogLevel (string $level is 'debug' | 'info' | 'warning' | 'error'): void {}
Of course, I don't think that a potential future scope of an in-draft RFC is reason to dismiss a more direct implementation of literal scalar types, but it may be useful to compare other ways we could achieve the same functionality. I personally find pattern matching within parameter/return types more versatile while keeping direct typing system more simplified. Specifically for a range feature that Ben Ramsey brought up, pattern matching for parameters seems much more appropriate.

All that being said, I would gladly welcome literal scalar types.

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

Hi,
This sounds very promising. But I would be confused about receiving a TypeError when just the value of the parameter is wrong.

As described in the RFC if I send 4 to a parameter that could only be 1, 2 or 3. I would expect a TypeError if I sent “abc” ?

Kind regards
Lars Nielsen

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 18:22:04 +0000

On Mon, 15 Jun 2026 at 12:28, Levi Morrison levi.morrison@datadoghq.com
wrote:

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at
17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):
class Option<+A>
{
 // B >: A means B is an ancestor of A
 // Since all As are Bs, you can return the A here
 function get_or_default: A>(Option $option, B $default): B
 {
 return $option->has_some()
 ? $option->get()
 : $default;
 }
 // todo: the rest of the implementation
}
You can't take A $default and return A because this violates the
variance laws: a covariant type A cannot be used in parameter
position. So alternatively you could solve this with inout A $default or similar.

Presumably this would work with the current proposal:

class Option<+A> {
    public function getOrDefault<B>(B $default): A|B {
        return $this->hasSome() ? $this->get() : $default;
    }
}

Hack also has super type constraints:
https://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constraints

[Discussion] Proposal: get_favicon() helper function

Mon, 15 Jun 2026 17:22:26 +0000

Hi internals,

My name is Sepehr and I would like to propose a small helper function for
PHP that extracts the favicon URL of a given page.

The function takes a URL, fetches the HTML, and returns the favicon URL as
a string.

Possible signature:

get_favicon(string $url): ?string

The function would scan the HTML for common favicon declarations such as:
<link rel=“icon” href=“…”> <link rel=“shortcut icon” href=“…”> <link rel=“apple-touch-icon” href=“…”>
If a favicon link is found, the function returns the URL. If not, it
returns null.

The goal is to provide a simple built-in helper for a common task in web
utilities and crawlers.

I would appreciate feedback on this. If it seems reasonable, I’d like to
draft an RFC and request a wiki account to create the proposal page.

Best regards,

Sepehr

Why is that a common thing so much that it needs to be part of the
language? Why can't you do it with existing Dom tools? Why does it have to
return null? Why does it take URL as an argument and simingly also return
it as well? Where does it fetch the HTML from? Does it do a http request
too?

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 17:19:54 +0000

It may be worth mentioning that within the Pattern Matching RFC future
scope, and mentioned a couple times within the discussion thread for the
RFC, there is a similar proposal that would allow for this without using
specific literal types.

It's outlined in
https://github.com/Crell/php-rfcs/blob/master/pattern-matching/future.md
under "Parameter or return guards"

It would allow for:

function setLogLevel (string $level is 'debug' | 'info' | 'warning' |
'error'): void {}

Of course, I don't think that a potential future scope of an in-draft RFC
is reason to dismiss a more direct implementation of literal scalar types,
but it may be useful to compare other ways we could achieve the same
functionality. I personally find pattern matching within parameter/return
types more versatile while keeping direct typing system more simplified.
Specifically for a range feature that Ben Ramsey brought up, pattern
matching for parameters seems much more appropriate.

All that being said, I would gladly welcome literal scalar types.

On Sun, Jun 14, 2026, 21:24 Seifeddine Gmati azjezz@carthage.software
wrote:

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 16:44:16 +0000

Hi Jordi,

Does the RFC allow referencing constants in type positions, or only raw
literal values?
function foo(STATUS_ACTIVE|STATUS_INACTIVE $sort): void {}

Regarding your first point, referencing constants in type positions is not
supported. This RFC focuses specifically on scalar literals. A constant
access is not a literal itself, and allowing something like FOO in a type
position could cause ambiguity; at first sight, it's unclear whether it
refers to a class name or a constant. While casing might suggest one or the
other to a human, PHP allows both classes and constants to use any casing
style, which could lead to confusion.

This would also be a BC break, as the following is currently permitted in
PHP:

const Foo = 1;
class Foo {}

function bar(Foo $hello): void {}

If Foo were changed to mean 1 instead of an instance of Foo depending
on the surrounding context, this would break existing applications.

What about enum values? For example:

function bar(Status::Active->value $status): void {}
// or simply as
function bar(Status::Active $status): void {}

For the second point, using enum values is also out of scope.
Status::Active->value is a runtime expression, not a literal: the engine
would have to confirm that Status is an enum, that the case exists, and
that it is backed before reading ->value. And Status::Active by itself
is an object, a single enum case, which would be a single-case type, a
separate feature from scalar literals. In both situations, requiring the
enum type itself is usually the better fit.

Also, I'm not really a fan of mixing literal types with unions.
function foo(int|'bar' $param): void {}

Finally, regarding mixing literal types with wider types like int|'bar',
this is supported by design. I believe restricting what may appear in a
union is the wrong approach; PHP should treat types uniformly, with
exceptions only for types that aren't value types and so are meaningless in
a union (void, never) or that are redundant (mixed|T, or a literal
already covered by its base type like int|1). If a union like
float|'cold'|'hot' lets a user express a real requirement for their API,
the type system should allow it.

Cheers,
Seifeddine.

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 16:26:00 +0000

Voting is now open on the Bound-Erased Generic Types RFC, as announced
in the Intent to Vote message earlier this week.

The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at 17:00 UTC.

RFC: https://wiki.php.net/rfc/bound_erased_generic_types
Discussion thread: https://news-web.php.net/php.internals/130816
Implementation: https://github.com/php/php-src/pull/21969

To my own surprise, I am voting yes on this proposal.

I still believe that refied generics should be the goal. To that end,
I think we should be able to merge this and in minor versions, fix
"soundness" and implementation holes as "bug" fixes on that route. If
internals can agree on this, and then the community can communicate
this through education, promotion, documentation, etc, then this RFC
is simply a useful stepping stone.

This is based on my own experience playing with the RFC, which
included reporting 2 bugs in the implementation on the RFC. To be
honest, it's not too useful to me. I very quickly run up against some
limitation when trying to build useful things. Most notably, we need
to be able to define lower bounds (syntax pending, obviously):

class Option<+A>
{
    // B >: A means B is an ancestor of A
    // Since all As are Bs, you can return the A here
    function get_or_default<B >: A>(Option $option, B $default): B
   {
       return $option->has_some()
           ? $option->get()
           : $default;
    }
    // todo: the rest of the implementation
}

You can't take A $default and return A because this violates the
variance laws: a covariant type A cannot be used in parameter
position. So alternatively you could solve this with inout A $default or similar.

This lower bound thing inevitably happens when I try working with
iterators too. But if the RFC passed, I would hope we could pass such
additional things without too much controversy.

[Discussion] Proposal: get_favicon() helper function

Mon, 15 Jun 2026 16:09:01 +0000

[Discussion] Proposal: get_favicon() helper function

Mon, 15 Jun 2026 15:35:15 +0000

Hi internals,

My name is Sepehr and I would like to propose a small helper function for
PHP that extracts the favicon URL of a given page.

The function takes a URL, fetches the HTML, and returns the favicon URL as
a string.

Possible signature:

get_favicon(string $url): ?string

The function would scan the HTML for common favicon declarations such as:

If a favicon link is found, the function returns the URL. If not, it
returns null.

The goal is to provide a simple built-in helper for a common task in web
utilities and crawlers.

I would appreciate feedback on this. If it seems reasonable, I’d like to
draft an RFC and request a wiki account to create the proposal page.

Best regards,

Sepehr

[RFC] Working Groups

Mon, 15 Jun 2026 15:20:15 +0000

Anything that doesn't need special powers can more efficiently be organized without the overhead of the initial RFC, as can also be seen by The PHP Foundation planning to launch 6 “special interest groups” in the remainder of 2026 without needing to involve the PHP project:

https://thephp.foundation/blog/2026/06/11/integrating-community- feedback-into-foundation-strategy-part2/#community-special-interest-groups

I'm aware of the PHP Foundation special interest groups, and Elizabeth and I discussed them before I opened the Working Groups RFC for discussion. We agreed they do not cover the same ground as the Working Groups RFC. By design, the PHP Foundation SIGs have no operational or governance authority over the PHP Project. There can be cross-pollination and collaboration between the initiatives, but the SIGs are external, community-focused, interest groups, while PHP WGs are internal, PHP Project-focused, operational groups.

My 2cents in the form of questions (because I might have missed something):

Since the PHPF's role is to support, help and discuss, then shouldn't
PHPF operatives be excluded from voting on RFCs, whatever the involved
WG? It would ensure that the PHP voters (aka "The community that
includes contributors and core team members") can take decisions
without the PHPF being able to intervene if there's a disagreement
between the two groups, I guess...?

"PHPF operatives" sounds very negative. Bear in mind, the Foundation currently employs a majority of the people who really understand the PHP engine and how to maintain it. Excluding them from voting would be.. project suicide.

The Foundation has no vote. The people who do half the work for PHP, who happen to work for the Foundation, have votes. As they should.

And similarly, shouldn't there be a mandatory consultation from the PHP
community when the PHPF actually operates on something that impacts the
community on non-RFC-mandatory-operations, like marketing,
communication, etc.? I mean, if at some point the PHPF communicates on
the web on something the PHP community would disagree with (concluded
via a vote of whatever sort), shouldn't the PHPF, as a "consultative
agency", have to update their acts and productions to fit to the
community's views? (that would solve parts of the issues with the
recent hot discussions on a certain link to a certain platform on PHP's
website, for example).

All these questions are here because PHP has no official governance
other than the (sometimes vaguely) designated "PHP Community", and the
PHPF's role, from what I understand, is mostly to help the community
to decide and act on PHP-related tasks, but not directly decide nor
act.

I might be off of some details, so feel free to correct me if I miss
something, if I'm mistaking, or if I misunderstand certain roles or
notions.

From the Foundation's home page:

The PHP Foundation is a collective of people and organizations relying on the PHP language. Its mission is to ensure the long-term prosperity of the PHP language.

The PHP Foundation focuses on providing financial support and guidance to PHP language developers to support its goals of improving the language for its users, providing high-quality maintenance, and improving the PHP language project to retain current contributors and to integrate new contributors.

The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors.

Read our announcement for more details.

That's what the Foundation does and is for.

It really seems like you're inventing problems that do not exist, and have no bearing on the project itself creating working groups. That those WGs may overlap with the Foundation, both in goal and personnel, is a good thing in my mind.

--Larry Garfield

[VOTE] Deprecate returning values from construct() and destruct()

Mon, 15 Jun 2026 14:56:32 +0000

Hi

I just opened the vote on “Deprecate returning values from __construct()
and __destruct()”.

RFC: https://wiki.php.net/rfc/deprecate-return-value-from-construct
Discussion: https://news-web.php.net/php.internals/130808

There is a single primary vote to cast. Voting closes 2026-06-29
14:00:00 UTC.

Best regards
Tim Düsterhus

Tim, sorry if I missed it in the discussion and RFC: is there any plan
to allow declaring function __construct(): void at the same time?
Since:

We are going to actively enforce that they don't return anything,
and returning void is the correct declaration for such functions
(and I would argue null as well but I don't care too much about
this, I debated mentioning it at all because it's a bit off in the
weeds),

doesn't it make sense to also allow declaring a void return at the same time?

Request for Wiki Account - Sepehr Mahmoudi:

Mon, 15 Jun 2026 14:22:14 +0000

Hi Sepehr,

Could you explain why this functionality should be part of PHP core rather
than a Composer package or framework-specific helper?

PHP is used in many contexts outside traditional websites (CLI
applications, daemons, APIs, desktop applications, etc.), and favicon
discovery appears to be specific to web applications.

Additionally, favicon locations are not standardized. Sites may use
/favicon.ico, HTML link tags, SVG icons, multiple icon sizes, CDN-hosted
assets, or framework-specific asset structures. Because of this, it is not
obvious how PHP core could reliably determine a favicon without making
assumptions about application structure.

It would be helpful to see more details about the prototype and the
specific problem that cannot be solved effectively in userland.

Regards,
Diogoagc

سپهر محمودی sepehrphpr@gmail.com escreveu em sáb., 13/06/2026 às 18:04 :

, Hi Internals
My name is Sepehr, and I am a web developer. I would like to request a
Wiki account to propose a new addition to the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting the
favicon file within the project structure without requiring parameters. I
believe having a standard, built-in way to handle this would improve the
developer experience and make PHP more web-integrated.
Requested Username: Sepehrphp
Email: sepehrphpr@gmail.com
I have a working prototype and I am ready to start the RFC process.
Best regards,
Sepehrphp

Request for Wiki Account - Sepehr Mahmoudi:

Mon, 15 Jun 2026 14:20:38 +0000

Le 13/06/2026 à 19:03, سپهر محمودی a écrit :

, Hi Internals
My name is Sepehr, and I am a web developer. I would like to request a
Wiki account to propose a new addition to the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting
the favicon file within the project structure without requiring
parameters. I believe having a standard, built-in way to handle this
would improve the developer experience and make PHP more web-integrated.
Requested Username: Sepehrphp
Email: sepehrphpr@gmail.com
I have a working prototype and I am ready to start the RFC process.
Best regards,
Sepehrphp

HTML already defines a way to configure favicons using the <link rel="icon"> tag and its internal parameters (media, type, etc.).

If no such link is defined in the HTML code, or if the page is not HTML
(pdf, json, image, etc.), most browsers will attempt at fetching the
"/favicon.ico" URL, which implies that it's becoming a standardized
method to both fetch an icon from a page AND create a fallback for any
HTTP server.

Plus, I wouldn't see the actual benefits of a "get_favicon()" function
that returns a "single URL", considering that the <link rel="icon">
tag's behavior is to adapt depending on several contextual information,
like "media" (which is basically a media-query), "type" (which is a
mime-type, allowing compatibility with lots of different formats) and
"sizes" which allows displaying different source media depending on the
final displayed size: the icon in the Windows taskbar will be smaller
than a shortcut for this website on a mobile's homepage, so the first
one can use a lightweight ".ico" image, and the last one can use a
scalable SVG for instance.

I'm curious about what exactly your RFC would provide.

Request for Wiki Account - Sepehr Mahmoudi:

Mon, 15 Jun 2026 13:41:02 +0000

Hi Sepehr

, I would like to request a Wiki account to propose a new addition to
the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting
the favicon file within the project structure without requiring
parameters. I believe having a standard, built-in way to handle this
would improve the developer experience and make PHP more web-integrated.

I have trouble understanding what it is this function would do exactly.
Can you describe that in a high level?

Thanks,
Ilija

[VOTE] Deprecate returning values from construct() and destruct()

Mon, 15 Jun 2026 13:23:45 +0000

Am 2026-06-15 15:19, schrieb Kamil Tekiela:

Just to clarify: return $this->privateVoidReturning(); will also
trigger a
deprecation?

Yes. This is consistent with return some_void(); in a function that
has an explicit : void return type:

 &lt;?php

 function foo(): void {
     return;
 }

 function bar(): void {
     return foo();
 }

see: https://3v4l.org/2cQYR#v

I'll make sure to add a corresponding test case to the implementation
for completeness.

Best regards
Tim Düsterhus

[PR #22159] ext/curl: expose SOCKOPT/OPENSOCKET/CLOSESOCKET callbacks

Mon, 15 Jun 2026 13:20:56 +0000

Hi internals,

PR #22159 adds three libcurl callback options to ext/curl for 8.6:

CURLOPT_SOCKOPTFUNCTION
CURLOPT_OPENSOCKETFUNCTION
CURLOPT_CLOSESOCKETFUNCTION

https://github.com/php/php-src/pull/22159

Motivation: give PHP users a native way to do SSRF filtering (validate the
resolved peer IP before connect) and low-level socket tuning
(SO_BINDTODEVICE, SO_MARK, keepalive, TCP_NODELAY...) without dropping to
ext/ffi.

Because the C signatures use a raw curl_socket_t fd, the callbacks bridge
to ext/sockets and exchange real Socket objects, fully usable with
socket_set_option(), socket_close(), etc.

Thanks to @devnexen who helped me to improve the dependencies management
and the low level integration.
CI is fully green (Linux, macOS, FreeBSD, Windows, ASAN).

Feedback welcome on any matter.

Thanks,
Xavier Leune

[VOTE] Deprecate returning values from construct() and destruct()

Mon, 15 Jun 2026 13:19:49 +0000

Hi

I just opened the vote on “Deprecate returning values from __construct()
and __destruct()”.

RFC: https://wiki.php.net/rfc/deprecate-return-value-from-construct
Discussion: https://news-web.php.net/php.internals/130808

There is a single primary vote to cast. Voting closes 2026-06-29
14:00:00 UTC.

Best regards
Tim Düsterhus

Just to clarify: return $this->privateVoidReturning(); will also trigger a
deprecation?

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 13:11:56 +0000

And to what I've read on the thread, the decision were made on this RFC, not on the concept of Generics itself.

I was responding directly to Daniil's comment starting "if this RFC is rejected...", not commenting on how anyone has voted.

If this RFC is rejected, it means only that this specific proposal is rejected, and there are plenty of options being discussed for alternatives.

I did not want a statement implying differently to stand unchallenged.

Rowan Tommins
[IMSoP]

[VOTE] Deprecate returning values from construct() and destruct()

Mon, 15 Jun 2026 13:09:08 +0000

I just opened the vote on “Deprecate returning values from __construct()
and __destruct()”.

RFC: https://wiki.php.net/rfc/deprecate-return-value-from-construct
Discussion: https://news-web.php.net/php.internals/130808

There is a single primary vote to cast. Voting closes 2026-06-29
14:00:00 UTC.

Best regards
Tim Düsterhus

[RFC] Working Groups

Mon, 15 Jun 2026 12:39:42 +0000

Anything that doesn't need special powers can more efficiently be
organized without the overhead of the initial RFC, as can also be
seen by The PHP Foundation planning to launch 6 “special interest
groups” in the remainder of 2026 without needing to involve the PHP
project:

https://thephp.foundation/blog/2026/06/11/integrating-community-
feedback-into-foundation-strategy-part2/#community-special-interest-groups

I'm aware of the PHP Foundation special interest groups, and Elizabeth
and I discussed them before I opened the Working Groups RFC for
discussion. We agreed they do not cover the same ground as the Working
Groups RFC. By design, the PHP Foundation SIGs have no operational or
governance authority over the PHP Project. There can be
cross-pollination and collaboration between the initiatives, but the
SIGs are external, community-focused, interest groups, while PHP WGs
are internal, PHP Project-focused, operational groups.

My 2cents in the form of questions (because I might have missed something):

Since the PHPF's role is to support, help and discuss, then shouldn't
PHPF operatives be excluded from voting on RFCs, whatever the involved
WG? It would ensure that the PHP voters (aka "/The community that
includes contributors and core team members/") can take decisions
without the PHPF being able to intervene if there's a disagreement
between the two groups, I guess...?

And similarly, shouldn't there be a mandatory consultation from the PHP
community when the PHPF actually operates on something that impacts the
community on non-RFC-mandatory-operations, like marketing,
communication, etc.? I mean, if at some point the PHPF communicates on
the web on something the PHP community would disagree with (concluded
via a vote of whatever sort), shouldn't the PHPF, as a "consultative
agency", have to update their acts and productions to fit to the
community's views? (that would solve parts of the issues with the recent
hot discussions on a certain link to a certain platform on PHP's
website, for example).

All these questions are here because PHP has no official governance
other than the (sometimes vaguely) designated "PHP Community", and the
PHPF's role, from what I understand, is mostly to help the community to
decide and act on PHP-related tasks, but not directly decide nor act.

I might be off of some details, so feel free to correct me if I miss
something, if I'm mistaking, or if I misunderstand certain roles or notions.

[RFC] [Discussion] Literal Scalar Types

Mon, 15 Jun 2026 12:09:05 +0000

Hello Internals,

I'd like to start the discussion on a new RFC adding literal scalar
types to PHP.

RFC: https://wiki.php.net/rfc/literal_scalar_types

Implementation: https://github.com/php/php-src/pull/22314

Thanks,
Seifeddine.

I mainly see the benefit here as being able to be more strict about what
a function actually accepts and returns, in cases where a dedicated enum
would be overkill.

Two things I'd like to understand better:

Does the RFC allow referencing constants in type positions, or only raw
literal values?

function foo(STATUS_ACTIVE|STATUS_INACTIVE $sort): void {}

What about enum values? For example:

function bar(Status::Active->value $status): void {}
// or simply as
function bar(Status::Active $status): void {}

Also, I'm not really a fan of mixing literal types with unions.

function foo(int|'bar' $param): void {}

To me, mixing these makes it harder to reason about what a function
actually accepts. The whole point of literal types is to be (more)
precise but the moment you throw a wide type like int into the union,
that precision goes out the window. If a function takes int|'bar', what
does that really tell me? It feels like it defeats the purpose.

--
Regards,

Jordi Kroon

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 11:36:40 +0000

Le 15/06/2026 à 10:51, Rowan Tommins [IMSoP] a écrit :

I agree 100%, voters should take responsibility for their own actions, instead of asking to hold off the vote indefinitely, constantly requesting changes.
I think it's generally preferable for the main aim to be reaching consensus, and a vote confirming that consensus, rather than treating votes as something to be "won" and "lost".

However, if there's genuine deadlock in a discussion, I guess bringing to a vote is a way to get a decision made.

The discussion thread on the internals list is already huge, so I guess
at least a substantial proportion of the people who voted have already
expressed themselves.

And to what I've read on the thread, the decision were made on this
RFC, not on the concept of Generics itself.

If this RFC is rejected, PHP won’t have generics (at least not in 2026/the first half of 2027 due to the cooling off period of RFCs of the same type).

That is, luckily, not what the policy says; it says "it will not be allowed to bring up a rejected proposal for another vote, unless ... the authors make substantial changes to the proposal". So an RFC building on Seifeddine's work but taking a different approach to enforcement could be brought forward at any time.

Holding a vote is not, and should not be, a way to block alternatives or counter-proposals.

Let's not get into the rhetoric of "this is your only chance for generics". If the vote is going ahead, people should vote on this specific proposal, with the specific tradeoffs it includes.

It's great that we're making progress towards generics; now let's work together to get the best version of them we can.

One of my interpretations is that "complete generics" isn't possible
per-se considering the current way the compiler and engine work.

However, it's not impossible to implement "generic-like systems", and
maybe a smaller RFC, for example about typed
arrays/ArrayObject/Iterator, could already bring a lot of value, without
having full generics yet.

[RFC] [Discussion] Bound-Erased Generic Types - non-voter feedback on the path forward

Mon, 15 Jun 2026 10:54:50 +0000

Hi internals,

I am not a voter, so please treat this only as feedback from a long-time
PHP user and backend/application architect.

I am aware that voting is already open for the Bound-Erased Generic Types
RFC. I am not writing to ask anyone to vote yes or no on the current RFC.
Rather, I would like to ask that PHP keeps a clear and credible path
toward generics after this vote, regardless of the outcome.

From a userland perspective, the need for generics is real. In large PHP
codebases, generic-like contracts already exist everywhere: repositories,
collections, serializers, DTO mappers, dependency injection containers,
event buses, pipelines, result/either types, iterators, hydrators, and
framework extension points.

Today, most of these contracts are expressed through PHPDoc and interpreted
by static analyzers, IDEs, and framework-specific tooling. That has allowed
the ecosystem to move forward, but it also means that one of the most
important parts of the program's type model is outside the language itself.

At the same time, I think the concerns about trust are valid. Native PHP
type declarations currently have a strong expectation attached to them:
when a developer sees a parameter type, return type, or property type in
PHP syntax, they can assume PHP itself enforces it.

If generic syntax weakens that mental model, PHP may gain nicer syntax but
lose some clarity in its type system. I do not think that would be a good
trade-off.

That suggests to me that the most important question is not only "erased
vs reified", but rather:

What kind of type information is this, and who is responsible for enforcing
it?

I would like PHP to have an explicit long-term type model with at least
these categories:

Runtime-enforced types, as PHP has today.
Compile-time or class-loading-time parametric constraints, especially
for inheritance, interfaces, abstract classes, method signatures, and
property types where this is possible.
Tooling metadata, useful for static analyzers, IDEs, Reflection-based
frameworks, and code generation, but explicitly not guaranteed by the
runtime.

If PHP adopts erased or partially-erased generics, I think the language
should make this distinction very explicit in documentation, Reflection,
and diagnostics. A developer should be able to tell whether a generic type
is enforced by PHP itself, validated during class loading or inheritance
checks, or merely preserved as structured metadata for tools.

As a possible path forward, I would personally prefer a smaller enforceable
subset first, even if it does not cover every use case that userland wants.

For example:

Generic interfaces first.
Generic abstract classes next.
Concrete classes implementing or extending them should bind type
parameters, unless PHP explicitly supports keeping those declarations
generic.
Substituted method signatures, return types, parameter types, and
property types should be checked by PHP where possible.
Reflection should expose structured generic metadata in a stable way.
Generic "new", generic functions, complex inference, generic compound
types, and runtime reification can remain future work.
Object-based collections can be built on top of that model before trying
to solve typed arrays.

This would not give PHP full generics immediately, but it would give the
ecosystem a trustworthy foundation. It would also let frameworks and
libraries start replacing PHPDoc templates with native declarations in the
places where there is an actual PHP-level contract behind them.

I believe this is important for more than syntax. A native and trustworthy
generic model would help static analysis, IDEs, framework design,
Reflection-based tooling, code generation, and potentially future optimizer
or compilation work. Without such a model, PHP can still continue to
improve, but a large part of its type information will remain fragmented
across PHPDoc conventions and external tools.

If the current RFC fails, I hope it is not interpreted as "PHP does not
want generics." I think a more useful interpretation would be that PHP
needs a generics roadmap with a clearer trust and enforcement model.

If the current RFC passes, I hope the same concern is still addressed:
the language should document very clearly which parts are enforced by PHP,
which parts are checked only by static analyzers, and which future steps
are expected to close the remaining gaps.

My main request is therefore:

Please do not let the generics discussion remain a binary choice between
"full reified generics now" and "PHPDoc forever."

A smaller, enforceable, explicitly staged model would already be a major
improvement for large PHP systems, and it would preserve trust in PHP's
native type syntax.

Thank you for all the work that has gone into this RFC and the discussion.

Regards,
<wheakerd

Containers. (was Re: Two-step creation for PHP modules)

Mon, 15 Jun 2026 09:45:18 +0000

Le 13/06/2026 à 19:14, Rowan Tommins [IMSoP] a écrit :

Namespaces in PHP are a bit of a hack - they prepend the stated namespace
to all labels declared in the file, and the use statement allows the fully
qualified name of a class, function or constant to be stated only once,
usually at the head of the file. It also allows aliasing, say if you have a
"Parser" class out of two different packages - you can alias them as
"FooParser" and "BarParser". It looks like Java or JavaScript importing,
but it isn't.
A small correction: this is exactly the same way that namespaces work in Java, with exactly the same implication: the fully qualified class name has to be globally unique. Java's solution to isolating an entire set of names is apparently to define an "Isolated ClassLoader": https://www.javathinking.com/blog/what-is-an-isolated-classloader-in-java/

C# also has this model of namespaces, but allows you to isolate a set of names from a particular "assembly" using an "extern alias" statement: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias

I suspect both mechanisms rely on details of their respective runtimes that wouldn't translate to PHP, but in principle what we're looking for is something similar.

Rowan Tommins
[IMSoP]

Namespaces being just a globally accessible and define-able symbols
system is exactly why, so far, a PHP package cannot define "private
internal" code. The way the language works already allows
autoload-hijacking in order to override code from external libs, or even
hack the visibility (like removing "final" or "private" keywords before
autoloading the file...).
After 18 years of PHP coding, including 15 years as a professional, I've
seen a huge lot of legacy PHP projects that benefit the language's
flexibility. Sure thing many of businesses could succeed thanks to being
able to override almost everything (contrary to stricter languages), but
maintaining these codebases with up-to-date versions of PHP, or
3rd-party libs, is so much of a hassle that, at some point, lots of
maintainers are going more and more into adding new things into PHP that
enforce a bit more strictness, opt-in of course. Some other libs (I'm
thinking about EasyAdmin, in the Symfony ecosystem, for example) have
even made the choice to close pretty much everything and provide
"maintainable" public entrypoints, enforcing the Open/Close principle
with a strict approach (immutable final classes, stricter options and
arguments, etc.). It has its pros and cons, and can be frustrating for
some devs, but the main goal was to make maintenance a bit easier for
the core devs so that they are not forced to maintain BC on too many layers.

Introducing Modules, whether they are based on namespaces or not, would
help maintainers, I think, and could reinvent how we think of PHP
packages, while still keeping PHP what it has always been because it
would be opt-in for maintainers.

On my side, I don't care if modules are tightly coupled to namespaces or
not, and if more, that's even why my first idea was to bind a module to
a single-file at first, and making all modules imported from such file
being non-importable-again, thus creating a single module tree that can
be stored at compile-time, have no side-effect at load-time (which is a
big safeguard to avoid other issues), and allowing multiple modules of
seemingly same name to be loaded in the memory at the same time,
similarly to how Node.js allows having different versions of the same
packages to be installed, while also allowing to have one version used
by many modules too.

The only drawback of having modules like that would be that final
dependency trees in Composer would be non-flat, but again, I think this
non-flat system should be opt-in. Similarly to how flat systems are
opt-in in the Node.js ecosystem (and trust me, I've tried to enforce
"flat" dependencies resolutions in certain Node projects, and it's a
huge hassle). Luckily, the PHP ecosystem is quite fine so far, compared
to Node, and I would definitely keep the "flat" system in Composer for
as long as possible, and make non-flat resolutions only case-specific
(which is rare, and usually framework-dependent, like with Wordpress
plugins for instance).

I still hope we could have a grouped discussion on this.

Larry's Modules proposal (here:
https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md )
is IMO a very good starting point, and it only lacks the "multiple
modules with different versions". And module definition with an INI file
looks interesting.

Adding a "container" system when importing a module can maybe allow
this, I don't know...?

@Michael: do you think you could start a new thread for PHP containers?
Do you already have some research that you could bring for a pre-RFC
discussion?

[VOTE] [RFC] Bound-Erased Generic Types

Mon, 15 Jun 2026 08:51:19 +0000

I agree 100%, voters should take responsibility for their own actions, instead of asking to hold off the vote indefinitely, constantly requesting changes.

I think it's generally preferable for the main aim to be reaching consensus, and a vote confirming that consensus, rather than treating votes as something to be "won" and "lost".

However, if there's genuine deadlock in a discussion, I guess bringing to a vote is a way to get a decision made.

If this RFC is rejected, PHP won’t have generics (at least not in 2026/the first half of 2027 due to the cooling off period of RFCs of the same type).

That is, luckily, not what the policy says; it says "it will not be allowed to bring up a rejected proposal for another vote, unless ... the authors make substantial changes to the proposal". So an RFC building on Seifeddine's work but taking a different approach to enforcement could be brought forward at any time.

Holding a vote is not, and should not be, a way to block alternatives or counter-proposals.

Let's not get into the rhetoric of "this is your only chance for generics". If the vote is going ahead, people should vote on this specific proposal, with the specific tradeoffs it includes.

It's great that we're making progress towards generics; now let's work together to get the best version of them we can.

Rowan Tommins
[IMSoP]

#externals

Spam on PEAR site

Should base_convert raise a notice/warning on precision loss?

Spam on PEAR site

Spam on PEAR site

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

Spam on PEAR site

[RFC] Separation of Third-Party Extension Documentation

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

[RFC] Working Groups

[RFC] Case sensitive PHP

Primary Constructors

Primary Constructors

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

[RFC] Function Autoloading (mark 5)

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

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

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

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

[RFC] Function Autoloading (mark 5)

[RFC] [Discussion] Literal Scalar Types

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

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

[RFC] Case sensitive PHP

[RFC] Case sensitive PHP

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

[RFC] Function Autoloading (mark 5)

[RFC] Function Autoloading (mark 5)

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

[RFC] Function Autoloading (mark 5)

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

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

[RFC] Separation of Third-Party Extension Documentation

[RFC] Separation of Third-Party Extension Documentation

[RFC] Separation of Third-Party Extension Documentation

[RFC] [Discussion] Literal Scalar Types

Containers. (was Re: Two-step creation for PHP modules)

[RFC] [Discussion] Literal Scalar Types

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

Containers. (was Re: Two-step creation for PHP modules)

[RFC] Working Groups

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

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

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

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

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

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

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

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

Containers. (was Re: Two-step creation for PHP modules)

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

[RFC] Working Groups

Regards Yuya

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Query Parameter Manipulation Support

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[VOTE] [RFC] Bound-Erased Generic Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Serializable closures from constant expressions

[VOTE] [RFC] Bound-Erased Generic Types

[RFC] [Discussion] Literal Scalar Types

[RFC] [Discussion] Literal Scalar Types

[VOTE] [RFC] Bound-Erased Generic Types

[VOTE] Deprecate returning values from __construct() and __destruct()

[VOTE] [RFC] Bound-Erased Generic Types

[RFC] [Discussion] Literal Scalar Types

[VOTE] [RFC] Bound-Erased Generic Types

Regards
Yuya

[VOTE] Deprecate returning values from construct() and destruct()

[VOTE] Deprecate returning values from construct() and destruct()

[VOTE] Deprecate returning values from construct() and destruct()

[VOTE] Deprecate returning values from construct() and destruct()

[VOTE] Deprecate returning values from construct() and destruct()