#externals

[META] This Week In PHP Internals | July 29, 2026

Sun, 02 Aug 2026 10:03:03 +0000

Hi Contributors,

This week's episode came out a few days late — it was recorded live at
Laracon US in Boston, and the trip home didn't cooperate. Here's the video,
plus everywhere else it landed for visibility.

As always, if I got something wrong, reply in this thread and I'll make
corrections. That includes how I'm pronouncing your names — I know some of
those still need work.

If you'd rather read than watch, the dev.to post carries the full episode
as an article, which also makes it the easiest version to quote when
correcting me.

youtube https://youtu.be/Af_8W6wxx6k
r/php
https://www.reddit.com/r/PHP/comments/1vdbx24/this_week_in_php_internals_july_29_2026/
r/symfony
https://www.reddit.com/r/symfony/comments/1vdc1g5/this_week_in_php_internals_july_29_2026/
r/laravel
https://www.reddit.com/r/laravel/comments/1vdc4zt/this_week_in_php_internals_july_29_2026/
dev.to
https://dev.to/projektgopher/this-week-in-php-internals-july-29-2026-45ge
mastodon https://phpc.social/@ProjektGopher/117024912100832320
threads https://www.threads.com/@projektgopher/post/DbiIVcnlK3d
bsky https://bsky.app/profile/projektgopher.com/post/3ms3p556ydf26
twitter https://x.com/ProjektGopher/status/2083848350277980393
linkedin
https://www.linkedin.com/feed/update/urn:li:activity:7489602847550939136/
pinkary
https://pinkary.com/@ProjektGopher/questions/019fc1e2-aaec-7143-bed3-ae909edd5ed5

Cheers,
Len

How to handle sensitive parameters to curl_setopt?

Sat, 01 Aug 2026 21:16:42 +0000

On Sat, Aug 1, 2026, 2:09 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
wrote:

Hello list,

I would like to reduce the chance that sensitive information passed to
curl_setopt is leaked. There's the SensitiveParameter attribute to prevent
parameters being exposed in stack traces. For example, openssl_encrypt has
its passphrase parameter marked as SensitiveParameter, so it won't be shown
in a stack trace. This mechanism doesn't work so well for curl_setopt,
which has the ability to set many options, both sensitive and not. The
value for CURLOPT_PASSWORD is likely sensitive, the value for
CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.

I have thought of the following solutions:

Mark the parameter as SensitiveParameter. This improves security,
but also obscures non-sensitive information. I am not sure how big of a
disadvantage that actually is? The curl error messages could already use
improvement, but when the value is hidden (because it's sensitive) it
becomes even more important to provide better errors.

Let curl_setopt determine whether to mark the parameter as
sensitive, depending on which option is being set. This is nice
functionally, but needs changes in the engine to store sensitivity of each
parameter in the stack, which comes with performance costs.
https://github.com/php/php-src/pull/22938

Be able to pass a SensitiveParameterValue to curl_setopt. This puts
the burden on the user to correctly wrap their sensitive values.
https://github.com/php/php-src/pull/22960

Not optimal, but some other options, all requiring userland intervention:

Additional optional boolean flag parameter to curl_setopt that, when
true, indicates that the value provided is sensitive and which flags to the
engine to wrap it in SensitiveParameter.
An integer constant that you | into the option name; when detected, the
engine wraps the provided value argument in SensitiveParameter.
Allow the engine to accept SensitiveParameter instances directly to any
function call. This would allow users to opt-in regardless of the function
signature.

The problem with curl_setopt is that auto detection will be difficult and a
game of whack-a-mole - considering opts are how you set HTTP headers and
content, which can be arbitrary. Allowing the user to determine what is and
isn't sensitive would allow more flexibility, and play nice with the
observer API for precisely the security use cases you describe.

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

How to handle sensitive parameters to curl_setopt?

Sat, 01 Aug 2026 19:29:36 +0000

On Sat, Aug 1, 2026 at 10:11 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
wrote:

Hello list,

I would like to reduce the chance that sensitive information passed to
curl_setopt is leaked. There's the SensitiveParameter attribute to prevent
parameters being exposed in stack traces. For example, openssl_encrypt has
its passphrase parameter marked as SensitiveParameter, so it won't be shown
in a stack trace. This mechanism doesn't work so well for curl_setopt,
which has the ability to set many options, both sensitive and not. The
value for CURLOPT_PASSWORD is likely sensitive, the value for
CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.

I have thought of the following solutions:

Mark the parameter as SensitiveParameter. This improves security,
but also obscures non-sensitive information. I am not sure how big of a
disadvantage that actually is? The curl error messages could already use
improvement, but when the value is hidden (because it's sensitive) it
becomes even more important to provide better errors.

Let curl_setopt determine whether to mark the parameter as
sensitive, depending on which option is being set. This is nice
functionally, but needs changes in the engine to store sensitivity of each
parameter in the stack, which comes with performance costs.
https://github.com/php/php-src/pull/22938

Be able to pass a SensitiveParameterValue to curl_setopt. This puts
the burden on the user to correctly wrap their sensitive values.
https://github.com/php/php-src/pull/22960

What do you think?

Regards,

Sjoerd

Stack traces are available on dev machines only unless everything is
misconfigured so I don't see how it can leak something. Imagine you
request an API with the wrong password because a co-worker changed it. How
would you know? Just my 2 cents.

--
Iliya Miroslavov Iliev
i.miroslavov@gmail.com

How to handle sensitive parameters to curl_setopt?

Sat, 01 Aug 2026 19:07:34 +0000

Hello list,

I would like to reduce the chance that sensitive information passed to curl_setopt is leaked. There's the SensitiveParameter attribute to prevent parameters being exposed in stack traces. For example, openssl_encrypt has its passphrase parameter marked as SensitiveParameter, so it won't be shown in a stack trace. This mechanism doesn't work so well for curl_setopt, which has the ability to set many options, both sensitive and not. The value for CURLOPT_PASSWORD is likely sensitive, the value for CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.

I have thought of the following solutions:

Mark the parameter as SensitiveParameter. This improves security, but also obscures non-sensitive information. I am not sure how big of a disadvantage that actually is? The curl error messages could already use improvement, but when the value is hidden (because it's sensitive) it becomes even more important to provide better errors.
Let curl_setopt determine whether to mark the parameter as sensitive, depending on which option is being set. This is nice functionally, but needs changes in the engine to store sensitivity of each parameter in the stack, which comes with performance costs. https://github.com/php/php-src/pull/22938
Be able to pass a SensitiveParameterValue to curl_setopt. This puts the burden on the user to correctly wrap their sensitive values. https://github.com/php/php-src/pull/22960
What do you think?

Regards,

Sjoerd

Request for RFC karma

Sat, 01 Aug 2026 08:13:32 +0000

Dear Internals,

I'd like to request RFC karma for kamazee wiki account.

A prior RFC about the minimum versions
(https://wiki.php.net/rfc/min_supported_versions_php_8_6) introduced few
BC breaks that can be observed even with newer DBMS versions which was
not mentioned in the RFC itself, and thus would like to propose another
way to handle the reset -- optionally, without breaking any of the
existing code. The author wasn't open to considering making the new flag
optional, so I would like to discuss it more explicitly with a wider
community.

Thanks,

Alex

[RFC] Function Autoloading (mark 5)

Fri, 31 Jul 2026 21:57:06 +0000

Hi Tim,

I posted this in the other thread, but I'm not sure it got through, so I'll repost here; apologies if both show up at once.

Without giving it detailed thought, I believe “Namespaced function, Autoload namespaced function, Global fallback” (i.e. swap steps 2 and 3) would result in much more predictable semantics already - the global fallback would work just as before, it just wouldn't have autoloading support.

Semantically, that makes most sense, but it leads to terrible performance for the global fallback case, unless there's some way to avoid multiple checks for the same namespaced function. That's why we keep going round in circles on the whole issue.

I think Michael's "namespace autoloader" idea is a much cleaner way forward - it avoids the fallback issue without creating lots of extra special cases, and in reality "load a file with all functions for namespace Foo\Bar" is likely to be more common than "load a file which specifically defines function Foo\Bar\baz()".

Regards,

Rowan Tommins
[IMSoP]

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 16:07:44 +0000

Hi Tim,

Without giving it detailed thought, I believe “Namespaced function, Autoload namespaced function, Global fallback” (i.e. swap steps 2 and 3) would result in much more predictable semantics already - the global fallback would work just as before, it just wouldn't have autoloading support.

Regards,

Rowan Tommins
[IMSoP]

[VOTE] Duration class

Fri, 31 Jul 2026 17:23:25 +0000

Wiki Page: https://wiki.php.net/rfc/duration_class
Discussion Thread: https://news-web.php.net/php.internals/131376

The RFC contains two votes:

One primary vote requiring a 2/3 majority to accept the proposal.

One secondary vote to decide on method naming, where the abbreviated
names will be selected if they reach a 2/3 majority, and the full names
otherwise.

Voting closes 2026-07-31 17:00:00 UTC.

Voting just closed. The RFC was accepted with 35 (Yes) to 1 (No) votes
and 2 Abstentions, which is 97%.

The secondary vote for the method names was in favor of full names with
30 of 32 votes (94%) and 3 Abstentions.

Best regards
Tim Düsterhus

[RFC] Function Autoloading (mark 5)

Fri, 31 Jul 2026 17:12:01 +0000

The RFC has been updated to un-incorporate the strict-namespace
elements; if there are no further substantive comments, I would like to
open the vote in 2-ish weeks.

To put my remark in the (canceled) voting thread into the correct place,
quoting myself from https://news-web.php.net/php.internals/132151:

Without giving it detailed thought, I believe “Namespaced function,
Autoload namespaced function, Global fallback” (i.e. swap steps 2 and
3) would result in much more predictable semantics already - the global
fallback would work just as before, it just wouldn't have autoloading
support. It's quite possible I'm changing my mind on that as well when
I think more about it […]

Best regards
Tim Düsterhus

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 17:10:21 +0000

I have edited the RFC to set the vote to "closed" -- let me know if
some other approach is preferred.

Thanks. You should also adjust the title of the voting widget to clear
out any votes and move the RFC in the overview back to “Under
Discussion”. Actual discussion of the RFC should then continue in the
discussion thread, I'll repeat my suggestion from my previous email
there to have a discussion starter and to bump the thread.

Best regards
Tim Düsterhus

[RFC] [Discussion] Literal Scalar Types

Fri, 31 Jul 2026 16:15:35 +0000

For what it's worth, I agree with your wider point: a vote that closes
at the freeze boundary leaves no room to react if implementation or
wider testing turns something up. Landing early in the next cycle is
the better home for a type-system change in any case.

I also agree here: This very much feels like a proposal that should land
early in the cycle, particularly due to the impact on existing
extensions and the ecosystem, which might have already started preparing
the adjustments for PHP 8.6.

I have just given the RFC another read and just have a very minor
comment regarding the vote:

The “Matching semantics for literal scalar types?” vote has no
explicitly stated tie-breaker. The RFC states “The author recommends
strict matching” which could be considered a tie-breaker in favor of
“strict matching”. But since we now have some time, you could as well
spell that out explicitly.

No further comments to the contents of the actual proposal. The cleanup
of the “accepted literal syntax“ section made the RFC much easier to
follow.

Best regards
Tim Düsterhus

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 16:03:37 +0000

Hi,

Hi

In fact the start of the vote is in violation of our policy, since there was no “intent to vote” message in the last 7 days.
Ah so -- my apologies. I'll pull the vote and wait for ... looks like ~6 weeks?

According to policy you could cancel the vote now, which results in a 2-week cooldown, which means you could theoretically re-open in the middle of August (after another “Intent to Vote”).

However given the preliminary voting results and under the assumption that folks didn't just vote against due to the policy violation, it is likely not useful to reopen the vote without making further changes - or without the circumstances changing (specifically your “Strict Namespace Resolution” RFC getting a decision). In any case, there will be plenty of time until PHP 8.7.

Without giving it detailed thought, I believe “Namespaced function, Autoload namespaced function, Global fallback” (i.e. swap steps 2 and 3) would result in much more predictable semantics already - the global fallback would work just as before, it just wouldn't have autoloading support. It's quite possible I'm changing my mind on that as well when I think more about it, but I wanted to provide some food for thought as to how the RFC could possibly be adjusted to make it better.

Sure, no hurry on my part. Can come back to it after 8.6 is fully out the door.

I have edited the RFC to set the vote to "closed" -- let me know if some other approach is preferred.

Thanks!

-- pmj

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 15:52:21 +0000

In fact the start of the vote is in violation of our policy, since
there was no “intent to vote” message in the last 7 days.

Ah so -- my apologies. I'll pull the vote and wait for ... looks like
~6 weeks?

According to policy you could cancel the vote now, which results in a
2-week cooldown, which means you could theoretically re-open in the
middle of August (after another “Intent to Vote”).

However given the preliminary voting results and under the assumption
that folks didn't just vote against due to the policy violation, it is
likely not useful to reopen the vote without making further changes - or
without the circumstances changing (specifically your “Strict Namespace
Resolution” RFC getting a decision). In any case, there will be plenty
of time until PHP 8.7.

Without giving it detailed thought, I believe “Namespaced function,
Autoload namespaced function, Global fallback” (i.e. swap steps 2 and 3)
would result in much more predictable semantics already - the global
fallback would work just as before, it just wouldn't have autoloading
support. It's quite possible I'm changing my mind on that as well when I
think more about it, but I wanted to provide some food for thought as to
how the RFC could possibly be adjusted to make it better.

Best regards
Tim Düsterhus

[RFC] [Discussion] Literal Scalar Types

Fri, 31 Jul 2026 13:43:12 +0000

Hey Matteo :)

Hi Pierre,

Il 31/07/2026 13:06, Pierre Joye ha scritto:

beta phases exist exactly for this reason. wider base of testers.

alpha is, heh, this is what we have so far, more or less stable, go test
it already!

RCs are everything should be stable, that's the final state, last
stage(s) for any bugs or breaks that didn't get caught earlier.

we should not expect "widely tested" new features, never released before
per se.

Yes indeed. But often unexpected side effects and breakages are caught
by various CIs running daily snapshots with OSS projects

right, and many use snapshot. and our ci is already very complete tbh. took
a while to make it green from a greenfield additions.

and yes, that's what beta are for :)

between the limited time induced by the updated policies, the Christmas
break "pls don't", and this, one needs to take holidays to make it
somehow as the time left in a year is low, very low, now.

I hear you, it's just that undoing or amending an RFC is a convoluted
process too, especially very late in the release cycle.

we are technically still in alpha.... it is not late. It is early in my
book ;-)

[RFC] [Discussion] Literal Scalar Types

Fri, 31 Jul 2026 13:39:22 +0000

Hi Pierre,

Il 31/07/2026 13:06, Pierre Joye ha scritto:

beta phases exist exactly for this reason. wider base of testers.

alpha is, heh, this is what we have so far, more or less stable, go test
it already!

RCs are everything should be stable, that's the final state, last
stage(s) for any bugs or breaks that didn't get caught earlier.

we should not expect "widely tested" new features, never released before
per se.

Yes indeed. But often unexpected side effects and breakages are caught
by various CIs running daily snapshots with OSS projects.

between the limited time induced by the updated policies, the Christmas
break "pls don't", and this, one needs to take holidays to make it
somehow as the time left in a year is low, very low, now.

I hear you, it's just that undoing or amending an RFC is a convoluted
process too, especially very late in the release cycle.

Cheers

Matteo Beccati

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 13:09:15 +0000

Hi

Per my message from a couple of weeks ago https://externals.io/message/131332#131945 I have opened the vote for Function Autoloading (mark 5):

https://wiki.php.net/rfc/function-autoloading-five-oh
The vote runs for two weeks and will close automatically at 14:45 UTC on Thu 13 Aug 2026.
N.b.: Voters concerned about shadowed global functions should note that such cases, while real in principle, are extremely rare in practice; those very few cases can be mitigated easily. Cf. https://wiki.php.net/rfc/function-autoloading-five-oh#how_common_is_the_shadow-global_case.
I think this is the best autoloading proposal up to date.
Most likely I would have voted yes if the target was 8.7, leaving us plenty of time to intervene in case of issues.
Perhaps I'm biased as RM, but last minute RFCs are making me nervous, I hope you understand.

In fact the start of the vote is in violation of our policy, since there was no “intent to vote” message in the last 7 days.

Ah so -- my apologies. I'll pull the vote and wait for ... looks like ~6 weeks?

Again, sorry for the hassle.

-- pmj

[RFC] [Discussion] Literal Scalar Types

Fri, 31 Jul 2026 11:06:40 +0000

Hey Matteo :)

Hi Seifeddine,

Il 30/07/2026 01:59, Seifeddine Gmati ha scritto:

I asked the 8.6 Release Manager about the feature freeze. The
effective cutoff is not the beta1 announcement on August 13 but the
creation of the beta1 tag, which happens on Tuesday, August 11,
mid-morning US Central time. A vote opened today would close on August
13, after the tag exists, so inclusion in 8.6 is not possible. I will
therefore not reopen the vote, and the Intent to Vote I posted on July
23 is withdrawn.

I have retargeted the RFC to the next PHP version, whether that is 8.7
or 9.0. RFC text is otherwise unchanged and remains final:
https://wiki.php.net/rfc/literal_scalar_types
I could have made an honest mistake when announcing the deadlines, but
all my emails were pointing the 13th as deadline for RFCs.

The rationale being that the implementation didn't have to land in beta1
necessarily, so the beta1 release date seemed better than "tagging day"
as deadline.

I think that having RFCs end voting so close to the feature freeze is a
terrible idea as it gives very little wiggle room in case something
unexpected comes out once implemented and more widely tested.

beta phases exist exactly for this reason. wider base of testers.

alpha is, heh, this is what we have so far, more or less stable, go test it
already!

RCs are everything should be stable, that's the final state, last stage(s)
for any bugs or breaks that didn't get caught earlier.

we should not expect "widely tested" new features, never released before
per se.

between the limited time induced by the updated policies, the Christmas
break "pls don't", and this, one needs to take holidays to make it somehow
as the time left in a year is low, very low, now.

That said, another RFC went to voting a few minutes ago, so we'd better

be consistent. I apologise for the confusion!

I can't talk for the author, you are in your role here :) applying
policies, even broken ones :)

--
Pierre

@pierrejoye

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 08:10:29 +0000

Per my message from a couple of weeks ago
https://externals.io/message/131332#131945 I have opened the vote
for Function Autoloading (mark 5):

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

The vote runs for two weeks and will close automatically at 14:45 UTC
on Thu 13 Aug 2026.

N.b.: Voters concerned about shadowed global functions should note
that such cases, while real in principle, are extremely rare in
practice; those very few cases can be mitigated easily. Cf.
https://wiki.php.net/rfc/function-autoloading-five-oh#how_common_is_the_shadow-global_case.
I think this is the best autoloading proposal up to date.

Most likely I would have voted yes if the target was 8.7, leaving us
plenty of time to intervene in case of issues.

Perhaps I'm biased as RM, but last minute RFCs are making me nervous, I
hope you understand.

In fact the start of the vote is in violation of our policy, since there
was no “intent to vote” message in the last 7 days.

I regretfully missed the email #131945 from two weeks ago, but also
didn't expect this RFC to go to vote, since:

The namespace-resolution-declare was just split out of it and in my
opinion having a decision on that first would be helpful to make an
educated decision on this one.
With the major change on the Wednesday, July 15th it was not able to
meet the soft freeze deadline that I calculated with (which should've
been Tuesday, August 11 according to policy).

As indicated during the discussion, I consider it unacceptable for the
autoloading to fail when a global function with the same unqualified
name exists. This adds further inconsistency to the language and I
expect the proposed behavior to be a source of bug reports from users
wondering why the autoloading doesn't work as expected.

Best regards
Tim Düsterhus

[RFC] [VOTE] Function Autoloading (mark 5)

Fri, 31 Jul 2026 07:57:35 +0000

Hi Paul,

Il 30/07/2026 16:46, Paul M. Jones ha scritto:

Hi all,

Per my message from a couple of weeks ago https://externals.io/message/131332#131945 I have opened the vote for Function Autoloading (mark 5):

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

The vote runs for two weeks and will close automatically at 14:45 UTC on Thu 13 Aug 2026.

N.b.: Voters concerned about shadowed global functions should note that such cases, while real in principle, are extremely rare in practice; those very few cases can be mitigated easily. Cf. https://wiki.php.net/rfc/function-autoloading-five-oh#how_common_is_the_shadow-global_case.
I think this is the best autoloading proposal up to date.

Most likely I would have voted yes if the target was 8.7, leaving us
plenty of time to intervene in case of issues.

Perhaps I'm biased as RM, but last minute RFCs are making me nervous, I
hope you understand.

Cheers

Matteo

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 18:56:40 +0000

On Thu, Jul 30, 2026 at 6:09 PM Christian Schneider
cschneid@cschneid.com wrote:

Am 28.07.2026 um 02:56 schrieb Osama Aldemeery aldemeery@gmail.com:

The flag only changes how an error is delivered. A call does exactly the same thing with it or without it, byte for byte.
The only difference is that at the end, any error the call would have recorded is additionally thrown, carrying the same code and
message preg_last_error()/preg_last_error_msg() would report.

Reading the RFC and specifically the line

// The detailed "Compilation failed: ..." warning is still emitted, as always.

I assume compilation (and other?) failures will then trigger BOTH the E_WARNING and an Exception?

This sounds weird to me, do we have a precedent for this behavior?
I would have expected the Exception to replace the E_WARNING.

Regards,

Chris

Hi Chris,

Good question, and you're reading it right: under the flag, a compile
failure emits both the E_WARNING and the exception.
One clarification though...That doubling only happens for compile
errors, which warn today.
Execution errors on the other hand (e.g. bad UTF-8, backtrack limit,
and so on) don't emit a warning at all, so those just throw.

On precedent, as far as I know there isn't a precedent for somethig like this.
But the reason it's currently warning-plus-exception rather than
exception-instead-of-warning is because the useful detail only lives
in the warning.
A compile failure sets the generic PREG_INTERNAL_ERROR / "Internal error" in the error functions, while the actual "Compilation failed: ... at offset N" text is only in the warning.
So if the exception replaced the warning today, you'd get an exception
saying "Internal error" and nothing about where or why.
Keeping the warning is what preserves that detail for now.

It's worth mentioning though that I do think
exception-instead-of-warning is the cleaner end state.
But it becomes the right move once the exception can carry that detail
itself, and that requires changing the message preg_last_message()
reports, which is the richer
compile-error reporting I've put under future scope.
Until then, dropping the warning would make the flag strictly worse
for debugging a bad pattern.

Happy to hear if you or others see it differently.

Thanks,
Osama

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 18:45:14 +0000

On Thu, Jul 30, 2026 at 3:22 AM B.J.Scharp <
php.list.internals@bitwise-operators.com> wrote:

Hi all,

The exception name is settled from the pre-RFC as \PregException
(thanks Tim) and the flag as PREG_THROW_ON_ERROR.

From the RFC:

The flag covers both classes of PCRE failure.

have you considered throwing different Exception types for the two
failure types? (e.g. PregExecutionException and PregCompilationException)

You could have both be child classes of PregException, but in actual
fact, the second should probably be a child of LogicException, while the
former really is a RuntimeException...

Regards,
Bernard

Hi Bernard,

Sorry, my last message got misformatted, so I am sending it again.

Thanks again for bringing this up.

As Rowan pointed out, the throwables policy settles half of it: additional
exceptions must extend the extension's base or each other, not the SPL
classes.
So the LogicException / RuntimeException parents are out regardless.

That leaves one PregException versus two under it (like your suggested
PregCompilationException / PregExecutionException), which is a judgment
call.
My starting point for the whole flag is that it only changes how an error
is delivered and nothing more.
That is the code and the message are exactly what preg_last_error() and
preg_last_error_msg() already give you.
A single exception sits most naturally on top of that.

There's a concrete nudge the same way....A compile failure only carries the
generic PREG_INTERNAL_ERROR / "Internal error" through the error
functions.
The real detail ("Compilation failed: ... at offset N") is in a warning,
not preg_last_error_msg().
So a PregCompilationException would carry "Internal error" and little
else until that detail is surfaced properly, which I've left as future
scope.

The upside of two types is letting people catch the two failure modes
separately.
I'm not sure how often that's needed in practice (given that
pre_last_error() already does not differentiate between them), but I
don't object if people feel
it's the better design.
For now I'd still favor the single PregException, with the door open.

Thanks,
Osama

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 18:36:52 +0000

On Thu, Jul 30, 2026 at 3:22 AM B.J.Scharp
php.list.internals@bitwise-operators.com wrote:

Hi all,

The exception name is settled from the pre-RFC as \PregException
(thanks Tim) and the flag as PREG_THROW_ON_ERROR.

From the RFC:

The flag covers both classes of PCRE failure.

have you considered throwing different Exception types for the two
failure types? (e.g. PregExecutionException and PregCompilationException)

You could have both be child classes of PregException, but in actual
fact, the second should probably be a child of LogicException, while the
former really is a RuntimeException...

Regards,
Bernard

Hi Bernard,

Thanks for bringing this up.

As Rowan pointed out, the throwables policy settles half of it:
additional exceptions must extend the extension's base or each other,
not the SPL classes.
So the LogicException / RuntimeException parents are out regardless.

That leaves one PregException versus two under it (like your
suggested PregCompilationException / PregExecutionException),
which is a judgment call.
My starting point for the whole flag is that it only changes how an
error is delivered and nothing more.
That is the code and the message are exactly what preg_last_error()
and preg_last_error_msg() already give you.
A single exception sits most naturally on top of that.

There's a concrete nudge the same way....A compile failure only
carries the generic
PREG_INTERNAL_ERROR / "Internal error" through the error functions.
The real detail ("Compilation failed: ... at offset N") is in a
warning, not preg_last_error_msg().
So a PregCompilationException would carry "Internal error" and
little else until that detail is surfaced properly, which I've left as
future scope.

The upside of two types is letting people catch the two failure modes
separately.
I'm not sure how often that's needed in practice (given that
pre_last_error() already does not differentiate between them), but I
don't object if people feel
it's the better design. For now I'd still favor the single
PregException, with the door open.

Thanks,
Osama

[RFC] [Discussion] Literal Scalar Types

Thu, 30 Jul 2026 16:55:27 +0000

Hi Seifeddine,

Il 30/07/2026 01:59, Seifeddine Gmati ha scritto:

I asked the 8.6 Release Manager about the feature freeze. The
effective cutoff is not the beta1 announcement on August 13 but the
creation of the beta1 tag, which happens on Tuesday, August 11,
mid-morning US Central time. A vote opened today would close on August
13, after the tag exists, so inclusion in 8.6 is not possible. I will
therefore not reopen the vote, and the Intent to Vote I posted on July
23 is withdrawn.

I have retargeted the RFC to the next PHP version, whether that is 8.7
or 9.0. RFC text is otherwise unchanged and remains final:
https://wiki.php.net/rfc/literal_scalar_types
I could have made an honest mistake when announcing the deadlines, but
all my emails were pointing the 13th as deadline for RFCs.

The rationale being that the implementation didn't have to land in beta1
necessarily, so the beta1 release date seemed better than "tagging day"
as deadline.

I think that having RFCs end voting so close to the feature freeze is a
terrible idea as it gives very little wiggle room in case something
unexpected comes out once implemented and more widely tested.

That said, another RFC went to voting a few minutes ago, so we'd better
be consistent. I apologise for the confusion!

Cheers

Matteo Beccati

Hi Matteo,

Thanks for clarifying, and no apology needed.

For this RFC the point is moot either way. My retarget announcement is
already out and, being a change to the voting widgets, it started a
fourteen-day Cooldown Period under the Feature Proposals policy. Even
under the August 13 reading, the earliest the vote could now open is
mid-August, so 8.6 was out of reach the moment that email hit the
list. The RFC stays targeted at the next PHP version.

For what it's worth, I agree with your wider point: a vote that closes
at the freeze boundary leaves no room to react if implementation or
wider testing turns something up. Landing early in the next cycle is
the better home for a type-system change in any case.

Good luck with the 8.6 releases.

Cheers,
Seifeddine

[RFC] [VOTE] Minimum supported versions for PHP 8.6

Thu, 30 Jul 2026 16:07:05 +0000

Hello all,

I'm announcing the start of the vote for the "Minimum supported
versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
UTC. There are multiple votes, one for each minimum version
requirement.

RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
Discussion: https://news-web.php.net/php.internals/131707

Thanks!
Eric

Hello!

The voting period has now ended for this RFC with the following outcomes:

"Implement autoconf 2.71 requirement as outlined in the RFC?" has
passed, with 27 votes for, 2 against, and 5 abstentions.
"Implement COM_RESET_CONNECTION requirement as outlined in the RFC?"
has passed, with 26 votes for, 0 against, and 5 abstentions.

Thank you all for your time, and for the time of those who will help
merge the implementations.
Eric

[RFC] [Discussion] Literal Scalar Types

Thu, 30 Jul 2026 15:28:20 +0000

Hi Seifeddine,

Il 30/07/2026 01:59, Seifeddine Gmati ha scritto:

I asked the 8.6 Release Manager about the feature freeze. The
effective cutoff is not the beta1 announcement on August 13 but the
creation of the beta1 tag, which happens on Tuesday, August 11,
mid-morning US Central time. A vote opened today would close on August
13, after the tag exists, so inclusion in 8.6 is not possible. I will
therefore not reopen the vote, and the Intent to Vote I posted on July
23 is withdrawn.

I have retargeted the RFC to the next PHP version, whether that is 8.7
or 9.0. RFC text is otherwise unchanged and remains final:
https://wiki.php.net/rfc/literal_scalar_types
I could have made an honest mistake when announcing the deadlines, but
all my emails were pointing the 13th as deadline for RFCs.

The rationale being that the implementation didn't have to land in beta1
necessarily, so the beta1 release date seemed better than "tagging day"
as deadline.

I think that having RFCs end voting so close to the feature freeze is a
terrible idea as it gives very little wiggle room in case something
unexpected comes out once implemented and more widely tested.

That said, another RFC went to voting a few minutes ago, so we'd better
be consistent. I apologise for the confusion!

Cheers

Matteo Beccati

[RFC] [VOTE] Deprecations for PHP 8.6

Thu, 30 Jul 2026 15:21:31 +0000

removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.

For native functions passing parameters in excess of the function’s
arity will throw an ArgumentCountError:

 php > define('X', 'X', true, 'extra');
 PHP Warning:  Uncaught ArgumentCountError: `define()` expects at most

3 arguments, 4 given in php shell code:1

Making it explicit (and deciding) that the parameter will go in PHP 9 is
a good thing.

Best regards
Tim Düsterhus

PHP 8.4.24 Released

Thu, 30 Jul 2026 15:14:34 +0000

The PHP development team announces the immediate availability of PHP
8.4.24. This is a security release.

All PHP 8.4 users are encouraged to upgrade to this version.

For source downloads of PHP 8.4.24 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_4_24.php
Downloads: https://php.net/downloads
Windows downloads: https://www.php.net/downloads.php?os=windows&version=8.4
Changelog: https://php.net/ChangeLog-8.php#8.4.24
Release Manifest: https://gist.github.com/NattyNarwhal/9ff44d1941f7fc5e84d4199b81d3888e

Many thanks to all the contributors and supporters!

Regards,
Calvin Buckley, Saki Takamachi, and Eric Mann

php-8.4.24.tar.bz2
SHA256 hash: 286890447588510df110ede9e9ce09f1eb4f9856630b47fdc40ece70e20373cf
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCammWlxsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaa5RQD/VHOaZLqLnznbHEWA3Yxt
iGHnZACVKQoyXcgRMvY0WB8BAPLbfSteqxsFAtPlFzqUqh/dzC32c8egQgCAToHe
G6sB
=Zpre
-----END PGP SIGNATURE-----

php-8.4.24.tar.gz
SHA256 hash: d5fe6a1d7633e70645dc757461eeb7b764ff6a04d0487f076dd56f1f9d8059db
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCammWlxsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaazbAD/ZN8l1G2PuGRCPz3saTDX
9+3qJmI0FNiO/jP90QoPKtUA/0vooLHOrTKlX9e+jEZYnPTRcitvVcw5rShKbftF
WvcP
=zbN3
-----END PGP SIGNATURE-----

php-8.4.24.tar.xz
SHA256 hash: e127be09a8506f4327c5cfa78a614b00d210714484ec215ce0011b4a03c00731
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCammWmBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMACgkQVql692AKOaYjxQEA4JM91wpTjDXkfFFmE/4C
BTe60xD1D1g9dpnNHEnJ0+MA/RkY5jNIdCTzjB3xinvrqB8xVx6tJYyigcfxNfZn
SqgG
=Lrrc
-----END PGP SIGNATURE

PHP 8.3.33 Released

Thu, 30 Jul 2026 15:11:43 +0000

The PHP development team announces the immediate availability of PHP 8.3.33. This is a security release.

All PHP 8.3 users are encouraged to upgrade to this version.

Release Announcement: https://php.net/releases/8_3_33.php
Downloads: https://php.net/downloads
Windows downloads: https://www.php.net/downloads.php?os=windows&version=8.3
Changelog: https://php.net/ChangeLog-8.php#8.3.33
Release Manifest: https://gist.github.com/ericmann/9ca630d036f957c356e01bbc39263d76

Many thanks to all the contributors and supporters!

Regards,
Eric Mann, Jakub Zelenka, and Pierrick Charron

php-8.3.33.tar.bz2
SHA256 hash: f9c9f4d0cd7692c6e3da363cd4ca72a826a49ae18f5ed430b6fcae7bc2881e18
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmpo7sMACgkQvsVV4ioU
NVOrwQ/+LeK0UPJUwMGPXeJKqjihpyqi03COjPe98F+5jp3XC+7Ie3BVcNIAOC5f
VPbXK2nzhUaLU+P6IJDshAj4kqTlKsg8lp6nH4Zpr4i20kTGIQoNiOzentkwLPGV
6PzmRspM63dbi2Mo8D6iqCuxXA+N22aGK8qmuhhgeYWw0QwXP+O4EPVprM9AiL/u
O9HwV9DG4LQGOpmdA3Tth8or1tlGkrzneolRXvqOtfUcLzaawOWjB99S2u4LfxwA
jSBgsS9LuBGzFElcXAorgtlrD0crFNdjvz5I7k4yZ/elIjf+KA4QXPrhdoaf9rJM
vMF65qqVahaT2shYgXNcl+ZQFh2aPM/y+RkngGefHoBmJqgxmCluY3yj6VMLJrkS
4PU4TeFxQG7bLqHQP5z0Mz5aJUxRAVYpHRD6k0dbqlt6V0tru6v8LST4DFkIL2tn
6oi3+Ysi3J+tlKP4vU04AFng6Wt8YzNyfNgZ6QLpvoTXbm1DizPhUvTfwgdw7cVa
XFwwJvS9daq2unnLI6mv4/ihgwkZYMtqpgVOYvkSnRXfZzfMwrxxT0z2T8AqjE16
qvCEvO28q8OEdIyzxpSOPu7PsUfkii2UOFVfMYPZFPjDOfBZxVhqN9f14kJh6oQE
6CYezWPIMcWDghzMOIE4Wldbw7+g4XwyDAoceULlKSatZ5gxfa0=
=6/Ik
-----END PGP SIGNATURE-----

php-8.3.33.tar.gz
SHA256 hash: f43566da482abeb1614a512dabeda74967847ce8e176a977390d7a115e7812fd
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmpo7sMACgkQvsVV4ioU
NVM27BAAnid4yO0Yyc91TngsBtUJTS37sujRGfNTc4FagupgLv7iwJU6ZYaYBKzo
iqog9ikjKuk1fpeFHgRVAHEFtXKy80EdFpYaydhpCXnTuVUFZn44DPDhnnTasP1R
H5+wZ2q7Ykko9CBMXTP3N7Zu4MrXa+w6j8ga6jtbDj44L1NC77rHaWm0rBEhonaD
aQHJ/Y8X5tIIoGY/TAtBJcP2wJX7doj7C1zUuq89EjUw8pdkas+buHsLCXqEI9qu
GaPbMGEPVLl50PldVrXteyB+Zm4g9PpCd4w84qJWkcNngKKgNluEeBuly40h10bq
kGUUuFiwZgi/qIAo+C1c1VeApAwY27TbedwJ5ez8D+tEzEr/O+kbuvW30b117fIt
rotN6LkuMSm+K4PA2EsbCkdYUwBtuyVtrx/Rgv+zPb5JBFJRhScI+0T8to+Suf6S
BtiIf/zAe/wU1FoV8zejqLzihO/tbCFHbhPtWDYyLET8Xy5RV33fNMu50tr0PPPF
k5rhIIUpj9OYi0GE8r2ZsmHHbAsSfawPxjDi6etOkZhXXoptqPVPRCi8UgG421Xz
B/5DxcGsd8Pl0SQJLWvcpu00suDo2XX3vLMzxzSZpO0XmPh3d/QLUMjK+vQ+lJbW
nFsGGMJVUe2DKN3YYnCRpfSempR0Lb9emPwLDnSMP1c3uVFwqjc=
=f1Uv
-----END PGP SIGNATURE-----

php-8.3.33.tar.xz
SHA256 hash: e293ed620cec74651bb4a071317892a478aa6840fab22db45c72d77cd42f9676
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmpo7sMACgkQvsVV4ioU
NVOQyhAAsx6xeijTn55N3e4Zhy0igfRXBfCdiwhuao6yD+mhzX8mNGyX/XKy7MHo
cHhV3HAKZuO2bqGvyGyAWOCGbdUa+qqZixMiXVexyZbv+1cQ1mItK2ogRMk3pFrv
umeDUSzG1GPDK4bj5FhJ4bXkWNet2IgN8EsfGMav6kDk+jZ4UAAs+3A8T9x30p8t
LjJJKsiUzfZ+I5sFQSpbbvJXc69SEthwAWbtiRcdCW5Y/jpK9w7hJ2M/vC/nIxh7
qRdpVqfLmgGZN5FmCum7VmuK6YZfMXm0wxmYKrBg9Evb59II1v1M5n+qlYBAkHTr
TokIDNNGWkLTZmCUvEmVoC7vtj0vqBNfWl5djBz7Vyikm5dltC2ecH63BCb8bVlv
2pc0ubw7VVExmf3ZJYXavaalrIca2zZeJO4bneVZ8tXaLieBoZZ5+GeAXpM2euO+
n0RHxB2TqHt8WwN0kkT8RLc+THnIMrDAZ34SOUqA6hs44exqmn9Ji2W0iy/nsurp
zkdkt9BKdEm160dqJXl9JEoadXQFi9IfmRrz5TL59NLuOH6DHP4cOZ6S80P7pksd
8anZmbSaTkP9gGUImqgMziD6bjwdBWx/RD7jezbDmTFZKl95VuEEotRaws87jyHH
qTyX9xqRJyak72wFAPKMhVn8H4peCsxbCvWGrfHfQRGls/PPCjA=
=lz/q
-----END PGP SIGNATURE

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 15:08:33 +0000

Am 28.07.2026 um 02:56 schrieb Osama Aldemeery aldemeery@gmail.com:

The flag only changes how an error is delivered. A call does exactly the same thing with it or without it, byte for byte.
The only difference is that at the end, any error the call would have recorded is additionally thrown, carrying the same code and
message preg_last_error()/preg_last_error_msg() would report.

Reading the RFC and specifically the line

// The detailed "Compilation failed: ..." warning is still emitted, as always.

I assume compilation (and other?) failures will then trigger BOTH the E_WARNING and an Exception?

This sounds weird to me, do we have a precedent for this behavior?
I would have expected the Exception to replace the E_WARNING.

Regards,

Chris

[RFC] [VOTE] Function Autoloading (mark 5)

Thu, 30 Jul 2026 14:46:21 +0000

Hi all,

Per my message from a couple of weeks ago https://externals.io/message/131332#131945 I have opened the vote for Function Autoloading (mark 5):

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

The vote runs for two weeks and will close automatically at 14:45 UTC on Thu 13 Aug 2026.

N.b.: Voters concerned about shadowed global functions should note that such cases, while real in principle, are extremely rare in practice; those very few cases can be mitigated easily. Cf. https://wiki.php.net/rfc/function-autoloading-five-oh#how_common_is_the_shadow-global_case.

Thanks!

-- pmj

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 14:22:24 +0000

Hi all,

The exception name is settled from the pre-RFC as \PregException
(thanks Tim) and the flag as PREG_THROW_ON_ERROR.

From the RFC:

The flag covers both classes of PCRE failure.

have you considered throwing different Exception types for the two failure types? (e.g. PregExecutionException and PregCompilationException)

You could have both be child classes of PregException, but in actual fact, the second should probably be a child of LogicException, while the former really is a RuntimeException...

Hi,

We actually have an agreed policy for this: https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables

According to that, there has to be a single base extension, which extends directly from \Exception.

Having more specific extensions is definitely encouraged, but these must all extend the extension's base exception (or each other), not any of the SPL classes like RuntimeException.

If it was a new extension the base exception name would be \Pcre\PcreException but there's flexibility when adding to existing extensions.

Thanks for bringing up this point,

Rowan Tommins
[IMSoP]

PHP 8.6.0alpha3 is available for testing

Thu, 30 Jul 2026 14:11:21 +0000

PHP 8.6.0alpha3 has just been released and may be downloaded from
https://downloads.php.net/~mbeccati/

Or use the git tag: php-8.6.0alpha3

This is an early test release and not intended for production use.

Windows binaries are available at: https://windows.php.net/qa/

Please test it carefully, and report any bugs at
https://github.com/php/php-src/issues/new?template=bug_report.yml
on GitHub.

8.6.0beta1 should be expected in 2 weeks, i.e. on 13 Aug 2026.

Hash values and PGP signatures can be found below or at
https://gist.github.com/mbeccati/a78ae3c3bafa22839c619d1c81d286ae

Thank you, and happy testing!

Regards,
Matteo Beccati, Joe Ferguson & Daniel Scherzer

php-8.6.0alpha3.tar.bz2
SHA256 hash:
34bf91f3c6f880ed196ff6855f850ec466a75540f78320540d367b349e49bf16
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCamiA8gAKCRCRNP8wvFqZ
tbBsAQDfOdq5Ge6ETCHxRT203UgPZ47w8mYn75gQpiTV/pl9sQEAuAmKRkBaLaw+
gxNcCWEvQN2Of66lu0KkpGnQX/1s+AA=
=bBxG
-----END PGP SIGNATURE-----

php-8.6.0alpha3.tar.gz
SHA256 hash:
e63ffdbae7ee90b43ce11b2ec16f62c6b623eec39c726060dba920af6088527b
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCamiA8gAKCRCRNP8wvFqZ
tSqrAQC8lU5+pYhKKGEPIo62x7ClzDzJfZexlxAcJAowQgJHLAEArH2XNTMNzyCC
jwiyve2FB1mAYA4lDt76aH6bho5TAwI=
=1+lj
-----END PGP SIGNATURE-----

php-8.6.0alpha3.tar.xz
SHA256 hash:
5eec9db06195860097005309eb6176309ae738df28f56eb23c87be5887d86c78
PGP signature:
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQBaJXemkdREdU3puaRNP8wvFqZtQUCamiA8wAKCRCRNP8wvFqZ
tXzqAP9aGMcN4vJXUWOSeDkMz7Dq+36pI1xuXduinoK/bQX83gEAiOLPPaYtDE6m
1unOIk4TM5i8eiE+WZ2FC+LmckQzoAc=
=NyTI
-----END PGP SIGNATURE

PHP 8.5.9 Released

Thu, 30 Jul 2026 13:16:37 +0000

The PHP development team announces the immediate availability of PHP
8.5.9. This is a security release.

All PHP 8.5 users are encouraged to upgrade to this version.

For source downloads of PHP 8.5.9 please visit our downloads page.
Windows binaries can be found on the same page.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://www.php.net/releases/8_5_9.php
Downloads: https://www.php.net/downloads.php?source=Y
Changelog: https://php.net/ChangeLog-8.php#8.5.9
Release Manifest:
https://gist.github.com/edorian/cfc86a2a5c79df2a51a20203ba7ad735

Many thanks to all the contributors and supporters!

Regards,
Volker Dusch, Daniel Scherzer, and Pierrick Charron

php-8.5.9.tar.bz2
SHA256 hash: 703c082ad9d2946ac647f3596812300d2c62b360d2f31a999021692a9b39476c
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCamirChsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1Fhb
AP9mohaDeKkWy1XfwYbp2nshB+bhxRsYaiyrhbmJfG4RcwD7BSwDi1jmYa+oqDXe
/OdWpGvH0lNaKAA1RZXn84vJbAo=
=lEmk
-----END PGP SIGNATURE-----

php-8.5.9.tar.gz
SHA256 hash: d735459c2cbaeb0673d416c33d372d9ff261d562f6b29da48f3e6aeaeca083af
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCamirChsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1Nna
AQDqYsBdDgY6yKHuUL57YJQK16cN/iLp7W9hSoM8LwNItwEAwj3wAB09eyHz37nm
Ts/Ef2E1Q0Z6gCBuOeqhly+2Dws=
=YHoj
-----END PGP SIGNATURE-----

php-8.5.9.tar.xz
SHA256 hash: 0db7855f25bcd0ab1d592cdb35e284d6f6a5d2ae0f6f621122e364cc39b708f4
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCamirChsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1L2Z
AQDvcR4sfJ9DkvPT9h1FXs0+Kz6F8m497RxBSJ78ejwlZgD/aqPD121W7HgCrQBG
bHCrDeekatbw43Fwz9/UKzmyNgg=
=ixq6
-----END PGP SIGNATURE

PHP 8.2.33 Released!

Thu, 30 Jul 2026 11:55:03 +0000

The PHP development team announces the immediate availability of PHP 8.2.33.

This is a security release.

All PHP 8.2 users are advised to upgrade to this version.

For source downloads of PHP 8.2.33 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_2_33.php
Downloads: https://php.net/downloads
Windows downloads: https://www.php.net/downloads.php?os=windows&version=8.2
Changelog: https://php.net/ChangeLog-8.php#8.2.33
Release Manifest: https://gist.github.com/saundefined/68ef63f3608373b939005f4bed504832

Many thanks to all the contributors and supporters!

Pierrick Charron, Sergey Panteleev & Ben Ramsey

php-8.2.33.tar.bz2
SHA256 hash: 5362f2a7a0e7168ce722fea0048b1a1d28e0f7cc265c417df670c65670695018
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmpogjgACgkQZZqXyc8q
eVrVUA//XGdv2a9uwKEYbALWhG1lfhjkUYcUHYbprbGWFxDeqtVdTEvDyAEOvG0j
HhmKL8/Lq5uzbBxjWvVd2YoDElFG3KW9Go0Xsa/X7T4EGe/JYV7AWafXbKyMFrW6
wjUiXIzUnjC/7VI5b7qd1MSivN+6XqY3AF6TbF1SQYnCU7rO7oiS6jWFX7ZMwJ2C
t0wLtrvSsKshGWPr/QkKYRmexVHCOgBhiG1XR5CupDci+zh4c4F0bXsCBgofK7mK
YA9CY4m9mnUnO7vVF7n9Haheg3MBSrhkwsL5w176fZmxgRHqHcXtR6ygAKuAT9dN
/n5okJXfy/Iai/ZLt0uNDw8v+r1ekPPXz/QnxY8w2p1nKp2I/m02bXvm0afLdKvu
8GcpzWRAJq+s681p61QeIpkNzxFQ6k/fcvQ6wNXa4rAFRi9oUDpItmWlEorL33Pa
k1kFErrlyL7Bqc59FXLe2hD/GuBrL15POWVq9DArMHUzDI7U7W/tGPYmUmPzbibE
Xx+guQEPWm9H/X3RomeVPrOhcNtfwaSSABRmIU4BSOMZkTdRHlAkN0vUdTmgleQC
wbo+Msv2t138/7iY1SzhmkGNtOS2rvkAt5wL6FW7AZ7VxiU/riC8hciUyuCrY4/n
OFB2Luf2iwME9TWYEDbvziB6oVbWYbWiVe8zlCntyfKvaWCjZcc=
=nM+5
-----END PGP SIGNATURE-----

php-8.2.33.tar.gz
SHA256 hash: 9a525d4db1237ede408e454b46f5a93b9e45d83d71753592e3f921903d917e07
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmpogj8ACgkQZZqXyc8q
eVpOAA//Uuu5S5amdIyWAITJg01GUqO4ka8frqgdna27Nm1Ya0lbdY4f1fxxSGkH
Ps3WU8C3iLTv5EbxSZ0eCc7wRibQ/vFPKFXgwHpwWllvZy1cuageXwLpmQjx9GjP
rtF1GbXlCWvHDA9vvOU6g6JYRgKkUNFfijXfzI4770+AVIRam3pzz7T32xK7fiDg
UMj1OAG/Y5F54NM4rNOvu1HZb8nBUdIGWe/NlvTmA62FJoMDStKPe6aadTWV98pR
Sy63LFIX/WmwL8csgN0M4o+wPjzH4munhAyAkhCMdXQp2pJ/ntOpOp9aBjy6LFyA
78QS51605Gyo8tGplmfEn3mPQQExNI5CGoDd5yRMDRCaZW3DJFP3d5kjF0WhymPU
u+MYK1JPTJGwMK53hvl7Y+d4RT2rYf55eI5L+Xcdl1fKPH10HzX29rccjRdsIVn6
rAgdS4LuY1G54yi8XEsBD1PSF0RtvNxeRj2XrZ2bAeXXYl1bXgZJ39mLRYg6apk8
rH/3z8nbkPJlI10eJ72gk0rLdMpkwCh2FCB4j2tM2QUkHhzz9yFznw+dOfnIX3ZL
VM9zFTIDDxem6m1sx893PIWQ9SOy32qQFBFG72JyzXajNz+r/Iy8313ONRT8vEqB
dyE6VsgD2VREmcwVEqm2dskJCWSrqhZ5GUABnMwW8uApOtOhyPA=
=woaV
-----END PGP SIGNATURE-----

php-8.2.33.tar.xz
SHA256 hash: fbdeace9b38220436a4c8fd79b900df92878151db145e641750743a283b514c1
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmpogkAACgkQZZqXyc8q
eVqmUQ//cw6ZWso1xaodTbTcXBVpdjy9f7s7irmm5ZEmK6KG1ksA/c/dLLPAGsmp
QuyoCUU62wZJFg2qXMslG4X5KS65+2q5pjp+WgV8L6QWZU4tupEJpEpEO1hiF6uL
bVbu+8vcWTNO/ZnuLh0xWdtqV5mcX9UDN0pG4fOqb+manWQVRgk3w4LnEE9hWMK0
C2ZUW7IE1LFLMawDEvMOPmphp+1mhIAAT6bLiiSzlVHUv975kPaVVw7Ou6CnHpaF
tv4Dvi5pKbOiSGba3nNEMQwQE8uLWo4CVvD5eA0kATRws5wdRz46EPrdcuXCOxZC
k1myAqeI7Tp3Ve+21zEMlm5dyOMmGJJlzI/OT05GTcNqomCJex4bLJrA5Utb4Htl
Hi9dchIEP5SPUF/IXJPvET4MQhFqdwf552tSHkpEb1jDMfnmDC8K33bJvHnVddOV
sRoWwtgfJA5lMR9fckek+6bZt7et+hNGhbzAfu9GwT+p5o6M0Vu8/3xLMGKHaL4A
7MsC+VhVvDG97mxOxibp44dJGajaR3VA+LmHg9xi7Dgja5it7apk21Vydf5zY6FU
LgB5ha/o91rltwpN3+IM0JUa3ratcTFJrB61lgqYPJ0Lkd0cQb9u+349n7RDRGJ+
hFLcspl4MUrKvv6FBCgs8ag55SHyViwuDTN64VouygH4z1g4AWw=
=VzAX
-----END PGP SIGNATURE

[RFC] [Discussion] PREG_THROW_ON_ERROR

Thu, 30 Jul 2026 00:21:29 +0000

Hi all,

The exception name is settled from the pre-RFC as \PregException
(thanks Tim) and the flag as PREG_THROW_ON_ERROR.

From the RFC:

The flag covers both classes of PCRE failure.

have you considered throwing different Exception types for the two
failure types? (e.g. PregExecutionException and PregCompilationException)

You could have both be child classes of PregException, but in actual
fact, the second should probably be a child of LogicException, while the
former really is a RuntimeException...

Regards,
Bernard

[RFC] [Discussion] Literal Scalar Types

Wed, 29 Jul 2026 23:59:00 +0000

Subject: Re: [RFC] 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 internals,

I have updated the Literal Scalar Types RFC to version 1.0, which I consider the final revision: https://wiki.php.net/rfc/literal_scalar_types

The changes are editorial, based on feedback in this thread. I merged the "Accepted literal syntax" section into the per-type sections so each literal kind is described in one place, added a paragraph to the introduction on where literal types fit next to enums, tightened the reasoning in the matching semantics section, and added a short note on enum comparisons to the Performance section. The proposal itself is unchanged: the syntax, the semantics and the three votes are the same as in 0.3.

Since this is a minor revision, I am opening voting shortly. A separate [VOTE] thread will follow.

Thanks to everyone who took part in the discussion.

Seifeddine

Hello internals,

A procedural update, following my retraction in the [VOTE] thread.

Earlier I opened voting on this RFC without meeting the prerequisites: no Intent to Vote had been posted two days in advance, and the 1.0 update I announced earlier is a Minor change, which starts a seven-day Cooldown Period. I retracted the vote. The widgets are closed, and the RFC is back to Under Discussion. The text is unchanged since the 1.0 announcement and I intend to keep it frozen until the vote.

Please consider this message my formal Intent to Vote. The Cooldown Period ends on July 30, and I plan to reopen the vote that morning (UTC), running for the standard fourteen days within the Intent to Vote lifetime.

One open question is the PHP 8.6 feature freeze. A vote opened on July 30 closes on August 13, the day of beta1, and the tag is created on August 11, so a merge would happen during the beta period and needs Release Manager approval. I am checking with the 8.6 RMs whether that is acceptable. If it is not, I will retarget the RFC to PHP 8.7 (or 9.0?) instead. Retargeting changes the voting widgets, so it would be announced here as a change, trigger its own Cooldown Period, and be followed by a fresh Intent to Vote, with no deadline pressure.

Thanks for your patience.

Seifeddine.

Hello internals,

An update on timing: this RFC will no longer target PHP 8.6.

I asked the 8.6 Release Manager about the feature freeze. The
effective cutoff is not the beta1 announcement on August 13 but the
creation of the beta1 tag, which happens on Tuesday, August 11,
mid-morning US Central time. A vote opened today would close on August
13, after the tag exists, so inclusion in 8.6 is not possible. I will
therefore not reopen the vote, and the Intent to Vote I posted on July
23 is withdrawn.

I have retargeted the RFC to the next PHP version, whether that is 8.7
or 9.0. RFC text is otherwise unchanged and remains final:
https://wiki.php.net/rfc/literal_scalar_types

Seifeddine

[RFC] [VOTE] Literal Scalar Types

Wed, 29 Jul 2026 23:53:52 +0000

Hello internals,

Voting is now open on the Literal Scalar Types RFC, as announced in the discussion thread earlier.

There are three votes on the RFC page, running concurrently:

Primary vote, requires a 2/3 majority: add integer and string literal types.

Second vote, requires a 2/3 majority, independent of the first: add floating point literal types. The RFC is accepted if at least one of the two type votes passes; if both fail, it is rejected.

Third vote, simple majority, effective only if at least one type vote passes: matching semantics, strict vs coercive. The RFC recommends strict matching.

The vote started on 2026-07-23 and ends on 2026-08-06.

RFC: https://wiki.php.net/rfc/literal_scalar_types
Discussion thread: https://news-web.php.net/php.internals/131249

Seifeddine
Cheers.

Hello internals,

An update on timing: this RFC will no longer target PHP 8.6.

I have retargeted the RFC to the next PHP version, whether that is 8.7
or 9.0. RFC text is otherwise unchanged and remains final:
https://wiki.php.net/rfc/literal_scalar_types

Seifeddine

[RFC] [VOTE]

Wed, 29 Jul 2026 16:49:35 +0000

> Nora isn't on the list, but she points out:
>
> The text for the metaphone deprecation isn't fully right. It lists
> "linguistics" as a replacement package, but that one actually uses
> php-src's metaphone internally too. So it is affected by the
> deprecation, not a replacement.
>
> As demonstrated by:
>
> <?php
> require 'vendor/autoload.php';
> \Linguistics\Phonetics::metaphone('foo');

Thanks for noticing.

Worth noticing that only the Phonetics::metaphone function use php's
metaphone(). Also, that function is barely a bridge for applying
existent functions of PHP. All other advanced algorithms ain't affected
by the metaphone deprecation.

My point in deprecating it is to stop using ancient metaphone algo as a whole.
And Linguistics offers loads of implementation. So this is still a replacement.
However, I do see the reason to make this clear in the RFC text.

I also forward this to Nora.

Weilin

[RFC] [VOTE]

Wed, 29 Jul 2026 14:03:30 +0000

Hello internals,

As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.

Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.

Best regards,

Gina P. Banyard

Nora isn't on the list, but she points out:

The text for the metaphone deprecation isn't fully right. It lists
"linguistics" as a replacement package, but that one actually uses
php-src's metaphone internally too. So it is affected by the
deprecation, not a replacement.

As demonstrated by:

<?php
require 'vendor/autoload.php';
\Linguistics\Phonetics::metaphone('foo');

[RFC] [VOTE] Deprecations for PHP 8.6

Wed, 29 Jul 2026 10:02:15 +0000

Hi,

Seeing this discussion during the voting phase makes me think the discussion phase wasn't properly completed yet, and I did a poor job in merging all opinions into a RFC proposal. I would rather not fuel the discussion any further, but I would prefer to let the voting play out.

Jakub Zelenka wrote:

The problem is that there wasn't enough time

I don't know your situation, but it seems you have quite a lot of work on your plate. Is there something I or anyone can do to reduce your load?

This is exactly a half baked deprecation because ... this does not give us any code removal and we still need to maintain it.

This is true, but my goal was to prevent abuse of the dechunk filter in filter chain attacks, not to reduce maintainance load. See also my PR to make filter chain attacks more difficult: https://github.com/php/php-src/pull/22110

to properly investigate if the things can be improved on the C side.

I tried some solutions, the most promising here: https://github.com/php/php-src/pull/22548

There was just some bug and then immediate proposal to deprecate it without first not even realising that it's used by chunked encdoing which I needed to point out.

For reference, this was in https://github.com/php/php-src/pull/22036, and there is some more information in https://github.com/php/php-src/issues/21983.

Regards,

Sjoerd Langkemper

[RFC] [VOTE]

Wed, 29 Jul 2026 09:24:12 +0000

Hello internals,

As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

Since Juliette kindly added some raw usage data, but proposers have refused to spend any time looking at it, I would like to point out that one of the uses found for "is" as a keyword is in Hamcrest, a cross-language test assertion framework. The PHP version has 500 million installs tracked by Packagist.

The is() function is part of the design inherited from the original Java library, and is used in many of the examples in the README so is likely to be widely used in the wild: https://github.com/hamcrest/hamcrest-php#usage

I think we should think very carefully whether we can avoid disrupting that much code.

Rowan Tommins
[IMSoP]

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 15:52:32 +0000

Hi,

Hey Jakub,

This is exactly a half baked deprecation because we need to keep it for
internal use anyway (it uses http stream wrapper for chunked encoding) so
this does not give us any code removal and we still need to maintain it. I
don’t understand why we need to rush it as there is no real reason for that.

Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don't think
this is something that can't be solved.

I actually resolved that select issue (if it's what I think it is -
limitation using select on filtered streams which I got rid of) in the
current master so it will be part of 8.6. See
https://github.com/php/php-src/pull/20540 .

Also we cannot just decide not to deprecate it in RC. We would need
extra approval from RM and then new RFC. We had exactly this sort of
situation last year with __sleep and it was huge pain to change. It also
took lots of our time that we could use for much more important stuff.

I hear you.

Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).

The problem is that there wasn't enough time to properly investigate if the
things can be improved on the C side. There was just some bug and then
immediate proposal to deprecate it without first not even realising that
it's used by chunked encdoing which I needed to point out. Then the idea
was to deprecate it for user space only which I actually wasn't against as
I assumed there was a proper research into the the usage but that wasn't
the case because Nicolas then pointed out that it is used in Symfony but
the deprecation proposal didn't get removed.

What I think is that deprecation should be proposed only if there a deep
knowledge of the problem and the context which I'm not sure is the case
here (and in some other proposals as well).

Kind regards,

Jakub

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 13:50:44 +0000

Hey Jakub,

This is exactly a half baked deprecation because we need to keep it for internal use anyway (it uses http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that.

Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don't think
this is something that can't be solved.

Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff.

I hear you.

Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).

Cheers,

Pierre

@pierrejoye

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 10:16:17 +0000

Hey Matteo,

Hi Pierre,

Il 28/07/2026 05:52, Pierre Joye ha scritto:

For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in

https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227

FYI, Symfony has implemented a pure-PHP alternative in 8.2:

https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2

That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:

stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);

in the code, if for whatever reason the Curl client is not in use.

I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.

Thanks :)

I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated

This is exactly a half baked deprecation because we need to keep it for
internal use anyway (it’s used http stream wrapper for chunked encoding) so
this does not give us any code removal and we still need to maintain it. I
don’t understand why we need to rush it as there is no real reason for that.

Also we cannot just decide not to deprecate it in RC. We would need extra
approval from RM and then new RFC. We had exactly this sort of situation
last year with __sleep and it was huge pain to change. It also took lots of
our time that we could use for much more important stuff.

Kind regards,

Jakub

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 08:58:47 +0000

Hey Matteo,

Hi Pierre,

Il 28/07/2026 05:52, Pierre Joye ha scritto:

For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227

FYI, Symfony has implemented a pure-PHP alternative in 8.2:

https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2

That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:

stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);

in the code, if for whatever reason the Curl client is not in use.

I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.

Thanks :)

I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated (not in project mentioned here tho' but many
internal code out there).

Cheers,

Pierre

@pierrejoye

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 07:36:25 +0000

Hi Pierre,

Il 28/07/2026 05:52, Pierre Joye ha scritto:

For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227

FYI, Symfony has implemented a pure-PHP alternative in 8.2:

https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2

That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:

stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);

in the code, if for whatever reason the Curl client is not in use.

I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.

Cheers

Matteo Beccati

[VOTE] Pipe Assignment Operator

Tue, 28 Jul 2026 04:24:20 +0000

Hi folks,

I just opened voting on the "Pipe Assignment Operator" RFC.

RFC: https://wiki.php.net/rfc/pipe_assignment_operator
Discussion: https://news-web.php.net/php.internals/131849

There is one primary vote requiring a 2/3 majority to pass.

Voting closes 2026-08-11 04:30:00 UTC.

Best,
Caleb

[RFC] [VOTE] Deprecations for PHP 8.6

Tue, 28 Jul 2026 03:52:42 +0000

Hello,

I think this should have not been proposed for deprecation yet. There are significant users of it and I just didn't have time to properly look into the issues. So there might be options to get it fixed properly. So I think it should wait till it's properly investigated.

I took a bit of time to actually check what is used, realistically,
beyond keywords presence stats.

I think there is some data/stats misinterpretation here. Being present
in a code base does not automatically mean it is used.

For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227

Guzzle and Symfony default to curl too. As curl is optional, I would
be surprised if a large majority of users do not have curl. Even more
surprised as, it is also a composer required dep.

Some SAPIs or php servers like FrankenPHP take over this as well
before PHP gets a hand on it. Please correct me here if my memory
fails here :)

From a http "end user" perspective, I would rather define that as
effectively not used.

The only part the deprecation does not address directly is the
fopen&co internal usages.

I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.

Cheers,

Pierre

@pierrejoye

[RFC] [Discussion] PREG_THROW_ON_ERROR

Tue, 28 Jul 2026 00:56:51 +0000

Hi all,

Following the earlier pre-RFC discussion (
https://news-web.php.net/php.internals/131783), I've written this up as a
proper RFC: https://wiki.php.net/rfc/preg_throw_on_error

Short version:

a PREG_THROW_ON_ERROR flag you pass to any preg_*() call, so a PCRE
error throws a \PregException you can catch
instead of a warning plus a false / null you have to notice and then
chase through preg_last_error().
Same thing JSON_THROW_ON_ERROR and FILTER_THROW_ON_FAILURE already do
for their functions.
It's opt-in, so nothing changes without the flag.

The flag only changes how an error is delivered. A call does exactly the
same thing with it or without it, byte for byte.
The only difference is that at the end, any error the call would have
recorded is additionally thrown, carrying the same code and
message preg_last_error()/preg_last_error_msg() would report.

For array arguments that means the flag mirrors preg_last_error()...it
throws whatever error the same call leaves there,
which for preg_replace() over an array is the last-processed entry, not
the first. (In the pre-RFC I'd floated throwing on the first failing
element instead).
Whether the preg_*() functions should stop at the first failing entry is
a separate question about those functions, one that applies with or without
the flag, so it's out of scope here.

The exception name is settled from the pre-RFC as \PregException (thanks
Tim) and the flag as PREG_THROW_ON_ERROR.

Target is the next feature release after 8.6 since 8.6's beta1 is too close
for this to conclude discussion and a vote in time.

I also saw Larry's note asking to hold new business that isn't targeting
8.6 until the freeze rush is over.
This won't catch 8.6, so I'm not asking for any priority while the freeze
is on. But the pre-RFC discussion was already open before
Larry's note, so I'd rather keep it ticking over quietly than restart it in
September.
If someone prefers I park it until then, please say so and I will.

Implementation and tests: https://github.com/php/php-src/pull/22797

Thanks,
Osama

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 16:23:53 +0000

Hi,

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filter

As things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.

I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".

I think this should have not been proposed for deprecation yet. There are
significant users of it and I just didn't have time to properly look into
the issues. So there might be options to get it fixed properly. So I think
it should wait till it's properly investigated.

Kind regards,

Jakub

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 15:30:21 +0000

Hi,

Hi,

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filter

As things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.

I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".

On a side note in this "official" thread, I added gd and gd2 image
related functions to the list. I suppose they don't need a vote, as I
don't see them either in the "removed" list. They will effectively not
be available in php 9. And GD itself will do a deprecation warning in
8.7.

Cheers,

Pierre

@pierrejoye

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 14:07:41 +0000

Hi,

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filter

As things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.

I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".

My 2c.

Cheers

Matteo Beccati

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 13:43:38 +0000

Hi

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.

Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.

It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.

and even if it was not, we should allow it.

If we would not, it would be a complete non sense and we need to sit down
to sort this out :)

--
Pierre

@pierrejoye

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 13:22:13 +0000

Hi

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.

Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.

It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.

Best regards
Tim Düsterhus

I have missed the "Deprecate define() with $case_insensitive being
specified" before it went to vote, but I wonder why do we need to
deprecate it. If the feature is gone and the deprecation happened
already in the past, then what's left is just to clean it up by
removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.

[RFC] [VOTE] Deprecations for PHP 8.6

Mon, 27 Jul 2026 12:46:14 +0000

As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.

Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.

It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.

Best regards
Tim Düsterhus

[RFC] [VOTE]

Mon, 27 Jul 2026 10:31:53 +0000

Hello internals,

As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6

The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.

Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.

Best regards,

Gina P. Banyard

Disallow newlines in CURLOPT_HTTPHEADER

Mon, 27 Jul 2026 10:12:40 +0000

Hi Sjoerd,

Given that Daniel Stenberg has said that newlines are not permitted, and is currently developing a pull request to reject them, does this change your view on whether PHP should reject newlines in headers passed to curl? Do you think I still need an RFC for this functionality?

My point of view is that libcurl will eventually take care of it. No pressing need to do anything on our side.

Cheers

Matteo Beccati

Disallow newlines in CURLOPT_HTTPHEADER

Mon, 27 Jul 2026 09:21:10 +0000

Hi Jorg, Matteo,

I wrote earlier:

It seems to me that this is exactly a case where this policy applies: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy

and:

I asked Daniel Stenberg about whether newlines are allowed in headers,
and he said:

The documentation says in clear terms:

The headers included in the linked list must not be CRLF-terminated

I believe libcurl might change its treatment of them in a future and
start
returning error earlier when such octets are found.

Though I'm also seeing https://github.com/curl/curl/pull/22309, which I
think concludes the question.

Given that Daniel Stenberg has said that newlines are not permitted, and is currently developing a pull request to reject them, does this change your view on whether PHP should reject newlines in headers passed to curl? Do you think I still need an RFC for this functionality?

Regards,

Sjoerd Langkemper

[PHP8.6] Soft feature freeze in 2 weeks

Mon, 27 Jul 2026 07:43:03 +0000

Hi everyone,

This is the two‑week reminder that the PHP 8.6 beta1 release is
approaching on Thursday, August 13, 2026.

The soft feature freeze happens two days earlier, on Tuesday, August 11,
when the beta1 tag is created. During the beta period, all features
(whether they require an RFC or not) may still be merged, but only with
Release Manager approval.

Under the updated release process, beta1 is the deadline for all RFCs
targeting PHP 8.6 to be fully decided. Any RFC intended for inclusion in
PHP 8.6 must have its discussion concluded and its voting closed before
August 13. New RFCs must therefore not target PHP 8.6.

The hard feature freeze occurs when RC1 is tagged on September 22, 2026.
After the hard feature freeze, no new features may be accepted. The
focus should shift entirely to fixing bugs, improving tests, and
preparing documentation for all accepted features.

The full schedule is available at:
https://wiki.php.net/todo/php86

Thank you all for your continued work and contributions.

Your 8.6 RMs,
Matteo, Joe, and Daniel

[RFC] [VOTE] Literal Scalar Types

Sun, 26 Jul 2026 18:58:36 +0000

Hey Juris,

Hello internals,

I am retracting this vote: I opened it prematurely, in violation of
the voting prerequisites in the Feature Proposals policy. I did not
post an Intent to Vote message at least two days in advance, and
today's 1.0 update to the RFC text is a Minor change announcement,
which starts a seven-day Cooldown Period during which no vote may be
called.

Hey all,

I'm a frequent reader/follower of this list as well as an occasional
participant and a one-time RFC-attempter. As such I never felt like
I'm "internal enough" to comment on the process. But since no one else
seems to be bothered by it, I would like to bring this up after all...

The "new" process (https://wiki.php.net/rfc/rfc_discussion_and_vote)
feels very discouraging to me. All the mandatory cooldowns, cooldown
resets on minor changes, announcements to vote, cooldown resets on
inactive discussions appears to me like bureaucratic hoops that people
have to jump through. The process was hard and daunting enough before
this.

I understand the extremes that the rules are preventing like someone
suddenly launching a vote for an RFC that has been dormant for 20
months. But in practice many of the mandatory cooldown resets,
activity bumps and other formal messages appear like only serving the
process. This case in particular feels very disappointing to me. The
discussion was done, the RFC text got finalized and it was a great
point in time to launch the vote on the finalized RFC. I see no
benefit of this setback of another week.

BR,
Juris

I fully agree on this, and that's why I voted against that proposal back
then.

On the other hand, we seem to have some contributors, who, sort of
intentionally want to slow down this, to not have the list overloaded
and have ample time to catch up with everything.

You sort of have to decide what you optimize for - easier for authors,
or easier for commenters. But I think in this case it went way overboard
in terms of strictness.

Bob

[RFC] [VOTE] Literal Scalar Types

Sun, 26 Jul 2026 18:15:55 +0000

Hello internals,

I am retracting this vote: I opened it prematurely, in violation of the
voting prerequisites in the Feature Proposals policy. I did not post an
Intent to Vote message at least two days in advance, and today's 1.0
update to the RFC text is a Minor change announcement, which starts a
seven-day Cooldown Period during which no vote may be called.

Hey all,

I'm a frequent reader/follower of this list as well as an occasional
participant and a one-time RFC-attempter. As such I never felt like I'm
"internal enough" to comment on the process. But since no one else seems
to be bothered by it, I would like to bring this up after all...

The "new" process (https://wiki.php.net/rfc/rfc_discussion_and_vote)
feels very discouraging to me. All the mandatory cooldowns, cooldown
resets on minor changes, announcements to vote, cooldown resets on
inactive discussions appears to me like bureaucratic hoops that people
have to jump through. The process was hard and daunting enough before
this.

I understand the extremes that the rules are preventing like someone
suddenly launching a vote for an RFC that has been dormant for 20
months. But in practice many of the mandatory cooldown resets, activity
bumps and other formal messages appear like only serving the process.
This case in particular feels very disappointing to me. The discussion
was done, the RFC text got finalized and it was a great point in time to
launch the vote on the finalized RFC. I see no benefit of this setback
of another week.

BR,
Juris

[RFC][VOTE] Allow Object Property Writes on Objects Referenced by Constants

Sat, 25 Jul 2026 17:21:37 +0000

Hi internals,

I am opening the vote for the RFC “Allow Object Property Writes on Objects
Referenced by Constants.”

RFC and voting: https://wiki.php.net/rfc/const_object_property_write

The vote will remain open for the standard two-week period and will close
on Saturday, August 8, 2026, at 23:59 UTC.

I would like to thank everyone who participated in the discussion and
provided feedback. The comments and suggestions helped improve the proposal.

Best regards,
__

Khaled Alam

[php-src] PR #20903: GH-10497 (const obj->prop write) - language change notes

Sat, 25 Jul 2026 15:07:19 +0000

Hi Khaled

As announced previously, I am now opening the vote for the RFC “Allow
Object Property Writes on Objects Referenced by Constants.”

RFC and voting: https://wiki.php.net/rfc/const_object_property_write

The vote will remain open for the standard two-week period and will
close on Saturday, August 8, 2026, at 23:59 UTC.

I would like to thank everyone who participated in the discussion and
provided feedback. The comments and suggestions helped improve the
proposal considerably.

You seem to be missing the abstain option, which is mandatory since
https://wiki.php.net/rfc/rfc_vote_abstain.

Ilija

[php-src] PR #20903: GH-10497 (const obj->prop write) - language change notes

Sat, 25 Jul 2026 14:22:01 +0000

Hey Khaled

Am 25.07.2026 um 15:48 schrieb Khaled Alam khaledalam.net@gmail.com:

Hi internals,

As announced previously, I am now opening the vote for the RFC “Allow Object Property Writes on Objects Referenced by Constants.”

RFC and voting: https://wiki.php.net/rfc/const_object_property_write

The vote will remain open for the standard two-week period and will close on Saturday, August 8, 2026, at 23:59 UTC.

I would like to thank everyone who participated in the discussion and provided feedback. The comments and suggestions helped improve the proposal considerably.

Best regards,

__
Khaled Alam

Could you please re-submit this mail in its own thread?
Titled "[RFC][VOTE] Allow Object Property Writes on Objects Referenced by Constants"

This gives it the correct visibility. Thank you!

Bob

[php-src] PR #20903: GH-10497 (const obj->prop write) - language change notes

Sat, 25 Jul 2026 13:48:56 +0000

Hi internals,

As announced previously, I am now opening the vote for the RFC “Allow
Object Property Writes on Objects Referenced by Constants.”

RFC and voting: https://wiki.php.net/rfc/const_object_property_write

The vote will remain open for the standard two-week period and will close
on Saturday, August 8, 2026, at 23:59 UTC.

I would like to thank everyone who participated in the discussion and
provided feedback. The comments and suggestions helped improve the proposal
considerably.

Best regards,
__

Khaled Alam

On Sat, Jul 18, 2026 at 2:39 AM Khaled Alam khaledalam.net@gmail.com
wrote:

Hi Tim and internals,

Thank you all for the feedback and discussion on the "Const object
property write" RFC over the past weeks

The RFC text has been stable since last weekend, and I believe the
remaining questions have been addressed.

I therefore intend to open the vote on Saturday, July 25th. The voting
period will run for the standard two weeks.

This gives us time to complete the vote and merge in time for the PHP 8.6
feature freeze.

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

If there are any final objections or concerns that should be resolved
before the vote opens, please raise them in the next few days so I can
address them before Saturday.

Best regards,
__

Khaled Alam

Hi

Thanks for catching these. I removed the accidental duplicate voting
content and added the RFC to the “Under Discussion” section of the RFC
overview page.

Thank you. You missed the status in the RFC itself, which I have now
done for you:

https://wiki.php.net/rfc/const_object_property_write?do=diff&rev2%5B0%5D=1783766078&rev2%5B1%5D=1783951590&difftype=sidebyside

I consider your change on Saturday to be the last (major) change to the
RFC. You may then open the vote on on July 25th. Vote must start no
later than July 28th to meet the deadline for PHP 8.6. Don't forget to
send the “intent to vote” 2-7 days before actually starting the vote.

Best regards
Tim Düsterhus

Stream Error Degradation: They're now missing what can't be opened

Fri, 24 Jul 2026 11:37:49 +0000

Hi,

Since the last few days, some of my tests for Xdebug started failing
with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master

Through commit https://github.com/php/php-src/commit/34c686a5b4ef, the
filenames and dirnames are removed as argument, from the warnings/errors
to include, require, etc — as a result of
https://wiki.php.net/rfc/display_error_function_args

While that is perhaps a noble goal, not showing which file couldn't be
included in many situations, such as:

Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d
Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9

And also in many other functions:

Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d
Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: finfo_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d

Doesn't seem to me like an enhanced for users, which would likely very
much to know which file is being included/required/bzopen'ed, etc.

I think we ought to fix this situations by included the file/directory
that can't be opened in the error messages themselves. Or if that is not
possible, then I would probably suggest to revert this change (even
though it was RFC'ed) until there is a possibility for not degrading the
usefulness of our error messages.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social

I think it's better the way it is now. The file path could leak
sensitive information, and having the option to control when it is
included in the error message is a good idea. However, the path is
already included in some error messages, so if we want to align the
behaviour that way, we can include the path in all stream error
messages. But I am against reverting the change from the commit.

FWIW, I always hated the stream warnings. In many situations, they
duplicate the error from the main operation, and they don't provide
meaningful information. For example, include already throws a warning
with the name of the file being included. If the open_basedir is in
effect, you will actually get 3 warnings for a single failure. Streams
shouldn't be raising their own warnings and instead return an error
code to the caller so that the caller can raise an appropriate
message.

Stream Error Degradation: They're now missing what can't be opened

Fri, 24 Jul 2026 10:51:37 +0000

Hi,

Since the last few days, some of my tests for Xdebug started failing
with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master

Through commit https://github.com/php/php-src/commit/34c686a5b4ef, the
filenames and dirnames are removed as argument, from the warnings/errors
to include, require, etc — as a result of
https://wiki.php.net/rfc/display_error_function_args

While that is perhaps a noble goal, not showing which file couldn't be
included in many situations, such as:

Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d
Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9

And also in many other functions:

Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d
Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: finfo_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d

Doesn't seem to me like an enhanced for users, which would likely very
much to know which file is being included/required/bzopen'ed, etc.

I think we ought to fix this situations by included the file/directory
that can't be opened in the error messages themselves. Or if that is not
possible, then I would probably suggest to revert this change (even
though it was RFC'ed) until there is a possibility for not degrading the
usefulness of our error messages.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social

[VOTE] Readonly Property Defaults

Fri, 24 Jul 2026 05:22:33 +0000

Hey everyone,

I just opened voting on the "Readonly Property Defaults" RFC.

Wiki Page: https://wiki.php.net/rfc/readonly_property_defaults
Discussion Thread: https://news-web.php.net/php.internals/131760

The RFC has one primary vote requiring a 2/3 majority to accept the
proposal.

Voting closes 2026-08-07 05:15:00 UTC.

Cheers
Nick

[RFC] Pipe Assignment Operator

Thu, 23 Jul 2026 11:24:09 +0000

Hi internals,
I'd like to open discussion on my (first!) RFC for the pipe assignment operator (|>=):
https://wiki.php.net/rfc/pipe_assignment_operator

It adds a compound assignment form of the pipe operator, so that
$x |>= callable is shorthand for $x = $x |> callable, with
support for chaining. Implementation with tests is at:
https://github.com/php/php-src/pull/22633

Looking forward to your feedback.

Thanks!
Caleb

Hi folks,

The discussion started 2026-07-09, last minor change was 2026-07-21 04:21 UTC;
therefore, the 7-day cooldown expires at 2026-07-28 04:21 UTC.

I intend to open voting on the Pipe Assignment Operator RFC on
2026-07-28 at ~04:30 UTC.

Thanks to everyone who provided feedback during discussion.

Best,
Caleb

[RFC] [DISCUSSION] ext/gd 2.4 — codec sync, Gd\* OOP API, 2D vector/canvas

Thu, 23 Jul 2026 11:23:27 +0000

Hi Pierre,

I should probably make this my last reply in this thread and see if others have anything to add, but I wanted to pick up on one point:

It makes it as nothing is being actually reviewed but rejected
straight down due to policies. Hence my bureaucracy statement.

I think if this was a small RFC, and people were refusing to read it because of a technicality, that criticism would be justified.

But I'm not sure it's entirely fair in this case. There are maybe twenty sections describing details of the proposal, and the crude "reading time" estimate in Firefox is 47-60 minutes. It may be clear in your head that most of this is uncontroversial, but for anyone else to even make that judgement requires investing a reasonable amount of time.

For many people, spending that time means spending less time on a different discussion. So it's not necessarily about bureaucracy, but a pragmatic decision: it's better to spend time now discussing proposals which are definitely targeting 8.6, and spend time later on proposals which will end up in 8.7.

That trade-off changes if we need to spend time deciding on the target version based on the content of each proposal, which is why I support the idea of a simple rule that everyone agrees in advance.

I do think there's an entirely separate question of when that hard cut-off should be. Should RFCs be allowed all the way through the alpha period? Should the alpha period be shorter, or later in some way? I've never been involved enough in the process to answer those questions.

Regards,

Rowan Tommins
[IMSoP]

[RFC] Concurrency Support in the PHP Engine

Thu, 23 Jul 2026 10:06:41 +0000

Hi Seifeddine,

Yes, perhaps this discussion has started a bit too early. But there's
no rush. I think waiting a couple of months is perfectly fine.

Regarding the note that this "would later let ob_start() and friends become coroutine-safe,"
I just wanted to mention that the possibility has been considered in
advance. Whether to actually use it or not can always be decided in a
separate RFC.
What's important to me is that this RFC doesn't rule out that possibility.

Regards, Ed

[RFC] Concurrency Support in the PHP Engine

Thu, 23 Jul 2026 09:56:52 +0000

Hi internals,

I would like to open the discussion of a new RFC:

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

The proposal gives the engine a coroutine representation and makes the
component that drives coroutines, the scheduler, pluggable by an
extension. It adds no classes, no functions, no constants and no
syntax: the engine compiles in no PHP symbols at all. With no scheduler
registered, PHP behaves exactly as it does today.

This is not the True Async RFC. It is the minimal engine core extracted
from that work: the activation contract, the notifications the engine
raises, adoption of fibers onto the scheduler, and per-coroutine
storage. Any user-facing API (spawn(), await(), channels) stays in
extension space; True Async is one possible provider on top, not the
subject of this proposal.

The implementation exists, and I am the one contributing it:

https://github.com/php/php-src/pull/22561

The PR carries the engine changes plus an in-tree reference scheduler
(ext/test_scheduler, disabled by default) that fills every slot from an
ordinary extension; the upstream test suites run unchanged and
schedulerless in the same binary. A bridge extension that registers a
scheduler written in plain PHP exists out of tree, as runtime proof
that the seam is sufficient.

Points likely of interest for existing code: a scheduler can adopt
fibers started by ReactPHP, Revolt or AMPHP, per fiber and declinable;
the proposal ships the per-coroutine storage that would later let
ob_start() and friends become coroutine-safe; there are no goroutines
and no parallelism, everything runs in one OS thread.

Feedback is welcome.

Regards,
Edmond

Hi Edmond,

The mailing list is quite busy right now, so I doubt this will get much
attention for the time being. I don't see this discussion taking place for
at least a couple more months, likely until 8.6 is out and RFCs for the
next version start landing.

Overall, I really like this idea and approach. I think this is the right
path forward.

Regarding the note that this "would later let ob_start() and friends become
coroutine-safe," I don't think they should be, but that is probably
unrelated to this specific RFC.

Regards,
Seifeddine.

[RFC] Concurrency Support in the PHP Engine

Thu, 23 Jul 2026 08:58:27 +0000

Hi internals,

I would like to open the discussion of a new RFC:

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

The proposal gives the engine a coroutine representation and makes the
component that drives coroutines, the scheduler, pluggable by an
extension. It adds no classes, no functions, no constants and no
syntax: the engine compiles in no PHP symbols at all. With no scheduler
registered, PHP behaves exactly as it does today.

This is not the True Async RFC. It is the minimal engine core extracted
from that work: the activation contract, the notifications the engine
raises, adoption of fibers onto the scheduler, and per-coroutine
storage. Any user-facing API (spawn(), await(), channels) stays in
extension space; True Async is one possible provider on top, not the
subject of this proposal.

The implementation exists, and I am the one contributing it:

https://github.com/php/php-src/pull/22561

The PR carries the engine changes plus an in-tree reference scheduler
(ext/test_scheduler, disabled by default) that fills every slot from an
ordinary extension; the upstream test suites run unchanged and
schedulerless in the same binary. A bridge extension that registers a
scheduler written in plain PHP exists out of tree, as runtime proof
that the seam is sufficient.

Points likely of interest for existing code: a scheduler can adopt
fibers started by ReactPHP, Revolt or AMPHP, per fiber and declinable;
the proposal ships the per-coroutine storage that would later let
ob_start() and friends become coroutine-safe; there are no goroutines
and no parallelism, everything runs in one OS thread.

Feedback is welcome.

Regards,
Edmond

[META] This Week In PHP Internals | July 22, 2026

Thu, 23 Jul 2026 06:58:09 +0000

Hi Contributors,

As promised, here's this week's video summary, along with a list of
everywhere else it got posted for visibility.

If you have any corrections you'd like me to make, please respond in this
weekly thread. Those corrections may also include mispronunciations of
names, because I'm still working on those.

The youtube link is going to be only video, but the dev.to post is going to
be the best way to read this as an article, which can also be quoted for
corrections.

youtube https://youtu.be/tCUKb5rPuJ4
r/php
https://www.reddit.com/r/PHP/comments/1v4426j/this_week_in_php_internals_july_22_2026/
r/symfony
https://www.reddit.com/r/symfony/comments/1v4471q/this_week_in_php_internals_july_22_2026/
r/laravel
https://www.reddit.com/r/laravel/comments/1v444zx/this_week_in_php_internals_july_22_2026/
dev.to
https://dev.to/projektgopher/this-week-in-php-internals-july-22-2026-4gij
mastodon https://phpc.social/@ProjektGopher/116967597163282396
threads https://www.threads.com/@projektgopher/post/DbH58iLFD_7
bsky
https://bsky.app/profile/did:plc:ix4islhkrpq7bjujwgsm234t/post/3mrc4c3ijtk2t
twitter https://x.com/ProjektGopher/status/2080179567424364857
linkedin
https://www.linkedin.com/feed/update/urn:li:ugcPost:7485943061298995200/
pinkary
https://pinkary.com/@ProjektGopher/questions/019f8d67-d772-7365-ac69-3ce25a4197dd

Really hoping that this visibility work encourages people to join the list
and start contributing themselves.

Cheers,
Len

[RFC] [Discussion] Literal Scalar Types

Thu, 23 Jul 2026 05:47:45 +0000

On Thu, 23 Jul 2026 at 06:13, Seifeddine Gmati azjezz@carthage.software
wrote:

Subject: Re: [RFC] Literal Scalar Types
On Mon, 15 Jun 2026 at 02:22, 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 internals,

I have updated the Literal Scalar Types RFC to version 1.0, which I
consider the final revision: https://wiki.php.net/rfc/literal_scalar_types

The changes are editorial, based on feedback in this thread. I merged the
"Accepted literal syntax" section into the per-type sections so each
literal kind is described in one place, added a paragraph to the
introduction on where literal types fit next to enums, tightened the
reasoning in the matching semantics section, and added a short note on enum
comparisons to the Performance section. The proposal itself is unchanged:
the syntax, the semantics and the three votes are the same as in 0.3.

Since this is a minor revision, I am opening voting shortly. A separate
[VOTE] thread will follow.

Thanks to everyone who took part in the discussion.

Seifeddine

Hello internals,

A procedural update, following my retraction in the [VOTE] thread.

Earlier I opened voting on this RFC without meeting the prerequisites: no
Intent to Vote had been posted two days in advance, and the 1.0 update I
announced earlier is a Minor change, which starts a seven-day Cooldown
Period. I retracted the vote. The widgets are closed, and the RFC is back
to Under Discussion. The text is unchanged since the 1.0 announcement and I
intend to keep it frozen until the vote.

Please consider this message my formal Intent to Vote. The Cooldown Period
ends on July 30, and I plan to reopen the vote that morning (UTC), running
for the standard fourteen days within the Intent to Vote lifetime.

One open question is the PHP 8.6 feature freeze. A vote opened on July 30
closes on August 13, the day of beta1, and the tag is created on August 11,
so a merge would happen during the beta period and needs Release Manager
approval. I am checking with the 8.6 RMs whether that is acceptable. If it
is not, I will retarget the RFC to PHP 8.7 (or 9.0?) instead. Retargeting
changes the voting widgets, so it would be announced here as a change,
trigger its own Cooldown Period, and be followed by a fresh Intent to Vote,
with no deadline pressure.

Thanks for your patience.

Seifeddine.

[RFC] [VOTE] Literal Scalar Types

Thu, 23 Jul 2026 05:44:21 +0000

Hello internals,

I am retracting this vote: I opened it prematurely, in violation of the
voting prerequisites in the Feature Proposals policy. I did not post an
Intent to Vote message at least two days in advance, and today's 1.0 update
to the RFC text is a Minor change announcement, which starts a seven-day
Cooldown Period during which no vote may be called.

The voting widgets are closed, and the RFC is back to Under Discussion. The
RFC text itself is unchanged and I consider it final.

I will post a proper Intent to Vote in the discussion thread and reopen the
vote once the Cooldown Period has passed, on or after July 30. The reopened
widgets will be retitled per the policy so that no stale votes carry over.

On timing: a fourteen-day vote opened on July 30 closes right at the August
13 feature freeze for PHP 8.6, and the beta1 tag lands on August 11, so any
merge would happen during beta in any case. I will coordinate with the 8.6
Release Managers on whether inclusion in 8.6 is still possible under RM
approval. If it is not, I will retarget the RFC to PHP 8.7 and announce
that change before reopening the vote.

Apologies for the noise.

Seifeddine,
Cheers.

[RFC] [VOTE] Literal Scalar Types

Thu, 23 Jul 2026 05:26:44 +0000

Hello internals,

Voting is now open on the Literal Scalar Types RFC, as announced in the
discussion thread earlier.

There are three votes on the RFC page, running concurrently:

Primary vote, requires a 2/3 majority: add integer and string literal
types.
Second vote, requires a 2/3 majority, independent of the first: add
floating point literal types. The RFC is accepted if at least one of the
two type votes passes; if both fail, it is rejected.
Third vote, simple majority, effective only if at least one type vote
passes: matching semantics, strict vs coercive. The RFC recommends strict
matching.

The vote started on 2026-07-23 and ends on 2026-08-06.

RFC: https://wiki.php.net/rfc/literal_scalar_types
Discussion thread: https://news-web.php.net/php.internals/131249

Seifeddine
Cheers.

[RFC] [Discussion] Literal Scalar Types

Thu, 23 Jul 2026 05:13:57 +0000

Subject: Re: [RFC] Literal Scalar Types
On Mon, 15 Jun 2026 at 02:22, 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 internals,

I have updated the Literal Scalar Types RFC to version 1.0, which I
consider the final revision: https://wiki.php.net/rfc/literal_scalar_types

The changes are editorial, based on feedback in this thread. I merged the
"Accepted literal syntax" section into the per-type sections so each
literal kind is described in one place, added a paragraph to the
introduction on where literal types fit next to enums, tightened the
reasoning in the matching semantics section, and added a short note on enum
comparisons to the Performance section. The proposal itself is unchanged:
the syntax, the semantics and the three votes are the same as in 0.3.

Since this is a minor revision, I am opening voting shortly. A separate
[VOTE] thread will follow.

Thanks to everyone who took part in the discussion.

Seifeddine

[RFC] [DISCUSSION] ext/gd 2.4 — codec sync, Gd\* OOP API, 2D vector/canvas

Thu, 23 Jul 2026 03:35:36 +0000

Hi Rowan,

On Tue, Jul 21, 2026 at 7:23 PM Rowan Tommins [IMSoP]
imsop.php@rwec.co.uk wrote:

hi Rowan,

A quick side-note, a reply that opens with at least a hello goes a
long way. It costs nothing and it is the difference between a review
and a brush off. We are not bots and don't talk to bots.

Hi Pierre,

I apologise completely for this. I often forget to add a greeting when
editing a reply, particularly on mobile. I definitely do not want to
sound rude or inhuman, so I will try to remember to include this in future.

Thank you, in the age of us talking more to machines than humans, that
is an important point to remind ourselves :).

However, to answer your question, It was important tot:

validate full compatibility of the libgd update with current php on
all platforms and supported features to date

it uses some "modern" C features, so a full blown validation on php
CIs is a must have first

Actual additions to php are thin layers now added in this thread
RFC. No more "business" logic in the binding itself but if needed to
handle older external versions.

That makes sense. I realise it's too late to say now, but it sounds like
the RFC text could have been presented in parallel to that
verification.

yes and no, given the newer C standard, dependencies and similar
changes, if any of that would fail and could not be fixed to be
supported in the current php's supported platforms and required CIs,
it would have forced some refactoring or rewriting. And maybe redo
part of the binding. That's something my time would not allow.

That would have given more time for people to digest the
new user-facing API, and suggest any changes without running as close to
the feature freeze.

It's quite common for implementations not to be finalised even when an
RFC is voted on, as long as changes don't impact what was agreed in the
RFC. The policy that has been formalised explicitly allows for that to
happen during the Beta period.

Right, since day #1 of RFCs :)

This is a PR and RFC that massively improves existing functions. Read:
everything under the hood, aside from the new APIs, is fixes and
improvements to what already exists. The new APIs themselves have zero
impact on existing functionality. They prepare PHP 9 and bring a much
more developer friendly way to do image operations. And the recurring
answer, too many times, has been "policies" or "wiki syntax."

I understand your frustration, and from what I've read, it looks like a
really great addition to the language.

But I do think its important that new features are given the time and
attention needed to refine small details. Names of new keywords or
classes, signatures of new methods, etc, are generally very easy to
change during an RFC discussion, but very hard to change once it's made
it into a stable release.

I understand. And realistically, f.e., say there are feedbacks to
update one codec method, or options, how they are named or called,
then all codecs change. They are not different, only different fields
in options.

Other methods like transform. scale or rotate are also pretty standard.

The 2D api is standard canvas-like APIs. Hard to do something
different and end as "php is different so we don't follow what
anything else does" :).

On the other hand, it's useful to have a cut-off point for new features
somewhere in the release process. If an RFC is in discussion close to
that cut-off point, there's always going to be an awkward decision: do
we cut off discussion because we're running out of time for the release,
or do we push the feature back a year so we can have the proper discussion?

Indeed.

Although it feels like bureaucracy, having a pre-determined cut-off date
can in theory make that decision easier: we don't have to debate for
every RFC whether it's "small enough" or "important enough" to carry on
discussing, we just have to ask "is it ready in time for the cut-off?"

And it is.

This release is still in alpha. Whatever the plan is for the next
beta, we're not at RC yet, and new approved features landing before RC
is exactly what we've reasonably expected before these non pragmatic
policies changes.

I'm not sure how strictly it was previously enforced, but the release
cycle update RFC from two years ago refers to the requirement for RFCs
to be voted before beta (but not necessarily merged) as an existing
policy: https://wiki.php.net/rfc/release_cycle_update

It was pragmatic and meant as a guideline and enforce minimal respect
of internals, RMs, and users. There is an obvious clear difference
between a RFC being accepted now without any implementation and one
with full implementation ready, all new APIs do not affect any
existing codes (obviously) and massively improving almost all existing
functions, for free, zero code change in userland.

That RFC actually made that deadline later, because it shortened the
overall timeline, moving the feature freeze from July to August; and
thus the RFC discussion deadline from June to July.

It makes it as nothing is being actually reviewed but rejected
straight down due to policies. Hence my bureaucracy statement.

Wherever that deadline falls, there will always be proposals which, for
whatever reason, are written close to it. Naturally, the authors of
those proposals will be frustrated at their change being held back until
the following year; but on its own, that's not a reason to ignore the
agreed cut-off date. Even if we allowed some discretion to land changes
after the deadline, it would need some justification - perhaps the RFC
is very small, or amends an existing RFC already in the release.

And the miss is counted in days. And I can already tell that the final
release will be delayed, anyway. Due to other stable branches having
various must have fixes that should be in all stable releases. So all
in all, pure hard core policies instead of pragmatism for the benefits
of our users.

To me, a well-documented process feels fairer than making subjective
judgements on the worthiness of every RFC.

Process has to be humane (thanks to someone well known on linkedin to
remind me of that word ;-). If they are purely for the sake of having
a process, we fail as a project and solve users' needs.

I will end, though, by saying I have no particular authority, and this
is all just my opinion. I wish you well, and look forward to digging
into your proposal, whichever release it ends up targeting.

Nobody has, many accept and confirm rejections. go figure :)

Cheers,

Pierre

@pierrejoye

[RFC] Pipe Assignment Operator

Wed, 22 Jul 2026 20:12:37 +0000

I do intend to try to get this into 8.6. Here's the schedule I'm planning:

Intent to vote: within the next day or so

Open voting: Monday July 28th ~04:30 UTC

Voting closes: Monday August 11th ~04:30 UTC

Except for the week-day correction that you noticed yourself, that would
be fully in line with policy and would also be meeting the soft freeze
deadline.

If the vote passes, what's the process for getting the PR merged?

If the vote looks favorable, I'll also have a look at the implementation
(so far I only looked at the tests, I also just added another test
review) and if it looks good to me then I'll find a second reviewer for
the implementation. You'll just have to make sure to react on the review
notes in a timely fashion.

That should hopefully result in the technical review being concluded
before the vote ends, so that the PR is immediately ready for merging.

Given that August 11 is also the day where Beta 1 is tagged, I'll ask
the RMs to merge the PR (if vote is accepted and implementation is
ready, of course) before tagging to avoid any timezone scheduling
issues. After that, PRs may only land with RM approval, but given it’s a
localized change and a small PR, I don't expect the approval to be
denied, but I obviously can’t speak for certain.

Best regards
Tim Düsterhus

[RFC] Pipe Assignment Operator

Wed, 22 Jul 2026 19:38:40 +0000

Hi Tim,

Thank you for all your help, patience, and guidance throughout this
process, especially as a first-time RFC author. And I really appreciate
you going to bat for this RFC in the thread---thanks again.

I do intend to try to get this into 8.6. Here's the schedule I'm planning:

Intent to vote: within the next day or so

Open voting: Monday July 28th ~04:30 UTC

Voting closes: Monday August 11th ~04:30 UTC

If the vote passes, what's the process for getting the PR merged?

Best,
Caleb

Apparently I got my days mixed up---07-28 and 08-11 are Tuesdays

Best,
Caleb

[META] Weekly Internals Summary Videos

Wed, 22 Jul 2026 19:32:24 +0000

Please please Google form, so that we don't flood the list with noise in this thread.

A form it is.

Yes to an off-list solution, but please don't use a Google (or other Big

Tech) form. The info you are asking, especially when all combined in one
form like you are suggesting, is pretty darn privacy sensitive and very
valuable to surveillance capitalist companies like Google.

Loud and clear. I'll roll my own solution

I'll post that link in this thread when I have time to whip that up, but
once I'm finished editing this week's episode I'm going to start a new
thread for corrections and errata.

[RFC] Pipe Assignment Operator

Wed, 22 Jul 2026 18:51:14 +0000

Thank you. The clarification makes sense to me and I don't have further
comments on the RFC.

As indicated in https://news-web.php.net/php.internals/132049, your RFC
could still be included in PHP 8.6. Even with this clarification, which
is a “minor change” you would be just in time. Any further change to the
RFC text will miss the deadline.

If you want to try to get into PHP 8.6, you'll need to open voting on
the 28th of July very shortly after 04:18 UTC until August 11th the same
time + a bit of buffer. You will also need to send an intent to vote
email at least 48 hours before that. The decision is up to you. I just
wanted to provide you with all the necessary information as a first-time
RFC author to make an adequate decision.

Best regards
Tim Düsterhus

Hi Tim,

Thank you for all your help, patience, and guidance throughout this
process, especially as a first-time RFC author. And I really appreciate
you going to bat for this RFC in the thread---thanks again.

I do intend to try to get this into 8.6. Here's the schedule I'm planning:

Intent to vote: within the next day or so
Open voting: Monday July 28th ~04:30 UTC
Voting closes: Monday August 11th ~04:30 UTC

If the vote passes, what's the process for getting the PR merged?

Best,
Caleb

[RFC] Pipe Assignment Operator

Wed, 22 Jul 2026 14:54:24 +0000

So the behavior is consistent with ??=. Bob, your observation about
optimizing intermediate chain fetches with ad-hoc references is
interesting, but that would be an improvement to all compound
assignment operators, not something specific to |>=.

I've updated the RFC to clarify this in the Single-Evaluation
Guarantee section.

Thank you. The clarification makes sense to me and I don't have further
comments on the RFC.

As indicated in https://news-web.php.net/php.internals/132049, your RFC
could still be included in PHP 8.6. Even with this clarification, which
is a “minor change” you would be just in time. Any further change to the
RFC text will miss the deadline.

If you want to try to get into PHP 8.6, you'll need to open voting on
the 28th of July very shortly after 04:18 UTC until August 11th the same
time + a bit of buffer. You will also need to send an intent to vote
email at least 48 hours before that. The decision is up to you. I just
wanted to provide you with all the necessary information as a first-time
RFC author to make an adequate decision.

Best regards
Tim Düsterhus

[META] Weekly Internals Summary Videos

Wed, 22 Jul 2026 14:20:15 +0000

I'm trying to ensure that contributors are properly
tagged/attributed/[at]mentioned on all these platforms, but I just
don't have a well built-out list of all of your social handles. I've
collected some of these from the internals Discord and through web
searches, but it's not enough. To collect these handles for platforms
like LinkedIn, Reddit, Twitter, Bsky, Threads, Mastodon, etc, would it
make more sense for you all to reply in this thread with all of your
handles, or should I create a simple Google Form and link that
instead?
Please please Google form, so that we don't flood the list with noise in this thread.

Yes to an off-list solution, but please don't use a Google (or other Big
Tech) form. The info you are asking, especially when all combined in one
form like you are suggesting, is pretty darn privacy sensitive and very
valuable to surveillance capitalist companies like Google.

[RFC] Typed array declarations

Wed, 22 Jul 2026 14:05:33 +0000

Base types would likely resolve the "value object" problem for lists: They would (I think) naturally pass like arrays, not like objects. However, it's fairly clear that we want to have methods on collection objects, not just free-floating functions, so if they're implemented as their own types then we would need to have extension functions for them to support a more robust standard library for them. If implemented as objects, we could use built-in methods or extension functions, but then we have to deal with the passing semantics problem.

We could save a lot of conversations if everyone just agreed that my Roadmap for 9.0 with implementations for Monomorphized Generics, Structs, Modules, Extensions, and Surfaces could be considered accepted as a rough outline for the future. PHP needs meaningful growth to avoid settling back into a 5.x slumber.

For anyone who hasn’t checked it out yet, I would encourage you to do so at https://EventuallyWrong.com/php9. I update it regularly as I expand my proposals. Most recently I added Generics. Variadic Generics will probably be added today as well.

[META] Weekly Internals Summary Videos

Wed, 22 Jul 2026 13:52:13 +0000

Hi contributors,

For the last 6 weeks or so, in an effort to make the PHP internals more
accessible and visible to a wider audience, I've been summarizing the
week's discussions into a ~10-15 minute weekly video, then breaking
that out into written content where it's supported, and threaded
content for other micro-blogging platforms.

I have two things to discuss:

I'm trying to ensure that contributors are properly
tagged/attributed/[at]mentioned on all these platforms, but I just
don't have a well built-out list of all of your social handles. I've
collected some of these from the internals Discord and through web
searches, but it's not enough. To collect these handles for platforms
like LinkedIn, Reddit, Twitter, Bsky, Threads, Mastodon, etc, would it
make more sense for you all to reply in this thread with all of your
handles, or should I create a simple Google Form and link that
instead?

Please please Google form, so that we don't flood the list with noise in this thread.

--Larry Garfield

[RFC] Typed array declarations

Wed, 22 Jul 2026 13:51:27 +0000

Hey Larry,

I am opposed to this RFC, for all the reasons Rob mentioned. Moreover, I don't believe the issues can be resolved by just waiting for the reified generics RFC (which I really hope passes). The core issue is that PHP arrays are an over-broad data structure, and we need to have a hard, type-based (not just implied by generics) distinction between lists/sequences, sets, and dictionaries/maps, the same way most languages do.

There are a few ways that could be done: 3 generic objects (a la Kotlin, my preferred approach), 3 generic objects with extension functions (assuming we can get those), 3 new core data types with extension functions (very hard to implement as I understand it), etc.
But tacking it onto the already-dangerously-overloaded array mega-type is the wrong approach.

Thanks for the feedback.
I understand the concern of adding more things to the array type and I
think it's a valid concern.

Would you think that an RFC adding new types, maybe using Kotlin as a
reference (as you mentioned), for having strongly typed array/list
structures would be a better fit?
I'd be happy to propose and work on this if this would be a better
direction/approach.

The challenge with new base types, AIUI, is that the way the engine works right now adding more types is really really hard. Building on top of objects is vastly easier. That's the biggest reason Enums were objects rather than their own base type. (There were other advantages to that approach, too, but implementation potential was a big one.)

Base types would likely resolve the "value object" problem for lists: They would (I think) naturally pass like arrays, not like objects. However, it's fairly clear that we want to have methods on collection objects, not just free-floating functions, so if they're implemented as their own types then we would need to have extension functions for them to support a more robust standard library for them. If implemented as objects, we could use built-in methods or extension functions, but then we have to deal with the passing semantics problem.

And in either case, we really, really want to have operator support.

I did some research on this topic a while back with Derick. My conclusion at the time was that we needed generics first, but once that was in then it was pretty straightforward, and by the end I had a clear-ish picture of the API I wanted. (Ignore the one-off syntax; we were considering that initially but decided to hold off and see if real generics were possible.)

https://github.com/Crell/php-rfcs/blob/master/collections/research-notes.md

(It's rather stream of consciousness, rather than a formal summary, so could flop around a bit.)

At this point, I think the best approach is to wait for reified generics and cross our fingers that it finally happens, then loop back and form a working group to decide on which way forward we want to take. The fate of extension functions would also impact the route taken here.

--Larry Garfield

SNMP module RFC implementation

Wed, 22 Jul 2026 13:08:14 +0000

Hi,

I have gone through the RFC process for a bunch of new functionality for
the SNMP module and wanted to check if there's anything else I need to
do to move this forward, or if it's in the queue and waiting for the
appropriate releases?

Hello Steven,

I'll have a look next week after I come back from a conference as I will need to learn about SNMP.

Best regards,

Gina P. Banyard

Hi Gina,

I've updated the security protocol PR based on your comment (I agree
with the suggested simplification), so that should hopefully be ready now.

I think I've fixed the formatting option PR as requested, with the
exception of the const definitions in the snmp.stub.php file. I've
extended the existing technique of using the values from the net-snmp
library, and I think it works quite well (it avoids having to map from
the PHP SNMP_* values back to the equivalent net-nsmp NETSNMP_*
values). All code in the php-snmp module checks that a valid value has
been passed before use. I will change this if you can see additional
benefits (I may need some guidance on the correct way to achieve this),
but I personally like the way the existing code works, and changing it
would require modifying the original php-snmp code.

Can you please have a look at the PRs for the 2 items above and let me
know if they are ready to squash and merge. Once the above 2 are done I
can rebase the third PR and get that ready for merging.

regards

Steve

Spam on PEAR site

Wed, 22 Jul 2026 12:11:18 +0000

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

I think it's safe to conclude that there is no PEAR team, the entire project is abandoned, and we need to decide what to do with the pear.php.net domain to protect the reputation of PHP.

Probably that means setting up a read-only mirror somewhere and pointing the DNS at it so that clients don't break overnight.

Just a heads-up: I would very much favour some form of a readonly
version of the site to stay available - probably with a banner that
this is only still available for archive purposes (and disable any
logins and form-submissions except admin).

I, for one, still semi-regularly have to go back to the issue tracker
on the PEAR site to dig up the reasoning/motivation for decisions
taken long ago for an old codebase, where the commit messages,
especially for older commits, are not great.

Not being able to do so anymore would definitely have some impact on
the work being done on that codebase.

Was just trying to dig up the background of some old bugfixes on the
PEAR website and when I click to see the details of an individual bug
report, I now get an "ERROR: the user who submitted this bug has not yet
confirmed their email address" page instead of seeing the bug details.
Example: https://pear.php.net/bugs/bug.php?id=20093

Clearly this is not helpful.

Not sure when this changed, but felt like something related to last
month's conversation, so I figured I'd flag it.

Smile,
Juliette

[RFC] Typed array declarations

Wed, 22 Jul 2026 11:03:15 +0000

Hey there Matheus,

plus: we may need to use turbofish syntax like array::<int, Product>

to avoid issues with the parser.

I didn't dive too much, but I don't think it's needed and we could make the
array syntax work like proposed in the RFC.

I don’t know where this fear comes from. I have monomorphized generics

implemented in a branch already using the standard C<T> syntax and it works
great. Combined with the struct proposal I also am sitting on until 8.6 is
finalized, they combine to form strongly-typed value-type data structures.

Exactly, I think this is very much doable, and since you already have a
working branch with that working shows that it is, thanks Holly.

---
Best Regards,
Wendell Adriel.
Software Engineer & Architect
https://wendelladriel.com https://wendelladriel.com

Em qua., 22 de jul. de 2026 às 04:19, Holly Schilling <
holly.a.schilling@outlook.com> escreveu:

plus: we may need to use turbofish syntax like array::<int, Product>
to avoid issues with the parser.

I don’t know where this fear comes from. I have monomorphized generics
implemented in a branch already using the standard C<T> syntax and it works
great. Combined with the struct proposal I also am sitting on until 8.6 is
finalized, they combine to form strongly-typed value-type data structures.

[RFC] Typed array declarations

Wed, 22 Jul 2026 11:00:58 +0000

Hey Michał,

I actually moved away from the direction I originally suggested (adding

element constraints to arrays). I'm now exploring a separate approach based
on dedicated immutable value types, but it's still too early to discuss as
a concrete proposal. I'd rather wait until the design has stabilized.

Interesting, I'll keep an eye out when you make this public!

---
Best Regards,
Wendell Adriel.
Software Engineer & Architect
https://wendelladriel.com https://wendelladriel.com

[RFC] Typed array declarations

Tue, 21 Jul 2026 21:04:11 +0000

My largest concern is that this proposal substantially overlaps with the reified generics RFC, which is being held until after the current code freeze in late August or early September at the earliest.

In particular, both proposals need to answer many of the same questions around parameterized types, variance, Reflection, runtime enforcement, inference, and type identity. I think we should avoid committing PHP to a separate set of array-specific rules before the broader generics proposal has been discussed. Otherwise, we risk either constraining the generics design or ending up with two parameterization models that behave differently.

plus: we may need to use turbofish syntax like array::<int, Product>
to avoid issues with the parser.

[META] Weekly Internals Summary Videos

Tue, 21 Jul 2026 19:14:39 +0000

Fennic: Thanks for the encouragement. I'm glad you're seeing value in it!

Rob: We'll see if this thread ends up in the final script, haha. "And this
week's human interest story: some dink named Len is asking everyone for
their social media handles"

Hi Len,

First off, Great work, I appreciate your effort to glean more
visibility into the goings on in the internals of PHP and you have a nice
presentation style for your videos and a soothing voice.

Secondly, anything you read from me, simply refer to as fennic.

Hi contributors,

For the last 6 weeks or so, in an effort to make the PHP internals more
accessible and visible to a wider audience, I've been summarizing the
week's discussions into a ~10-15 minute weekly video, then breaking that
out into written content where it's supported, and threaded content for
other micro-blogging platforms.

I have two things to discuss:

I'm trying to ensure that contributors are properly
tagged/attributed/[at]mentioned on all these platforms, but I just don't
have a well built-out list of all of your social handles. I've collected
some of these from the internals Discord and through web searches, but it's
not enough. To collect these handles for platforms like LinkedIn, Reddit,
Twitter, Bsky, Threads, Mastodon, etc, would it make more sense for you all
to reply in this thread with all of your handles, or should I create a
simple Google Form and link that instead?

To maintain accuracy, I want to include publishing the video link here
to the internals list as part of my publishing workflow each week. I hope
this provides an easy path for anyone who feels I've misunderstood or
misrepresented their messages to correct me, allowing me to include a
'corrections and errata' segment in the videos. If we find that we're
having to do multiple corections each week, then I'll probably post the
first draft to the list and allow comments and corrections during an ~8hr
window before filming.

The data cutoff is weekly at 10pm Vancouver time (UTC-7) each Tuesday
evening. First draft of the script is usually ready by 11:30 PM, and
filming generally starts at 9:30am the subsequent Wednesday morning.
Publishing is usually finished around ~5pm that same Wednesday. I'm working
hard to speed this up, but it's an iterative process.

I'm going to include the link to last week's video here so that we can
address any necessary corrections, and I'll also a list of the platforms
where I posted it. If anyone has ideas for other platforms where this
visibility work might be appreciated, I'd love to know them. I've also been
submitting to laravel-news, and the phpweekly newsletter.

youtube https://youtu.be/cGNa33qGqEg
r/php
https://www.reddit.com/r/PHP/comments/1uxnmsp/this_week_in_php_internals_july_15_2026/
r/symfony
https://www.reddit.com/r/symfony/comments/1uxnuq0/this_week_in_php_internals_july_15_2026/
r/laravel
https://www.reddit.com/r/laravel/comments/1uxntqb/this_week_in_php_internals_july_15_2026/
dev.to
https://dev.to/projektgopher/this-week-in-php-internals-july-15-2026-4nhb
mastodon https://phpc.social/@ProjektGopher/116926982520569384
threads https://www.threads.com/@projektgopher/post/Da1bNf_lL-r
bsky https://bsky.app/profile/projektgopher.com/post/3mqq27xvmac2s
twitter https://x.com/ProjektGopher/status/2077559023998816461
linkedin
https://www.linkedin.com/feed/update/urn:li:share:7483325450434400256/

Thanks everyone for your help and support (especially on Discord), and
I'm eager to keep this thing going.

Cheers,
Len

You are going to include this email discussion in your video? right? :)

— Rob

[RFC] Typed array declarations

Tue, 21 Jul 2026 14:59:34 +0000

pon., 20 lip 2026, 17:22 użytkownik Larry Garfield larry@garfieldtech.com
napisał:

Hi Wendell,

Thanks for updating the RFC.

My largest concern is that this proposal substantially overlaps with
the reified generics RFC, which is being held until after the current
code freeze in late August or early September at the earliest.

In particular, both proposals need to answer many of the same questions
around parameterized types, variance, Reflection, runtime enforcement,
inference, and type identity. I think we should avoid committing PHP to
a separate set of array-specific rules before the broader generics
proposal has been discussed. Otherwise, we risk either constraining the
generics design or ending up with two parameterization models that
behave differently.

My second concern is the proposed variance model. It is extremely
complex for a mutable built-in collection. Collections are normally
invariant unless their API clearly separates reading from writing. The
generics RFC follows that model: generic parameters are invariant by
default, and covariance or contravariance is permitted only where their
usage can be proven safe.

Here, an array<Dog> is treated as compatible with array<Animal>
only at selected by-value boundaries, based on PHP's copy-on-write
separation. It then becomes invariant for writable aliases and requires
additional rules for shared references.

That does not appear to establish a normal subtype relationship. It
establishes context-dependent boundary compatibility whose soundness
depends on engine-level array separation and reference behavior. I
think that will be challenging for users to understand and difficult
for the engine to enforce consistently.

Making parameterized arrays invariant would be substantially simpler:

array<int, Dog> !== array<int, Animal>

If covariance is desirable, I think it should come from a separate
read-only collection or interface rather than from mutable arrays.

My third concern is the one-argument syntax:

array<TValue>

This implicitly means:

array<int, TValue>

That is surprising. It is not a general array of values because string
keys are rejected, but it is not a list either because the integer keys
need not be contiguous or zero-based. I would expect array<TValue> to
constrain only the value type, with the key type remaining
int|string. A future list<TValue> could express the more
restrictive numeric-keyed form.

Lastly, I am concerned about repeated runtime validation. Since
ordinary arrays do not retain a trusted element-type identity, an
untyped boundary loses any information established by an earlier check:

function foo(array<Bar> $arr): int
{
$acc = 0;
foreach ($arr as $bar) {
    $acc += $bar->count;
}

return $acc;
}

function bar(array $arr): int
{
return foo($arr);
}

$arr = get_super_huge_array();
echo bar($arr);

At the call to foo(), PHP must recursively validate the entire array
again, even if the same array was previously checked elsewhere. For
large or nested arrays, this makes a type declaration potentially
introduce an O(n) or recursive O(n) cost at every typed boundary.

This is another reason I think typed arrays should be considered
together with the wider generics design. A broader design may be able
to provide type identity, inference, specialized collection types, or
another mechanism that avoids repeatedly rediscovering the element type
by traversing the value.

I would strongly prefer that this RFC wait until the reified generics
RFC has been discussed, or at minimum limit itself to syntax and
Reflection experimentation without committing to independent variance
and runtime semantics.

— Rob
I am opposed to this RFC, for all the reasons Rob mentioned. Moreover, I
don't believe the issues can be resolved by just waiting for the reified
generics RFC (which I really hope passes). The core issue is that PHP
arrays are an over-broad data structure, and we need to have a hard,
type-based (not just implied by generics) distinction between
lists/sequences, sets, and dictionaries/maps, the same way most languages
do.

There are a few ways that could be done: 3 generic objects (a la Kotlin,
my preferred approach), 3 generic objects with extension functions
(assuming we can get those), 3 new core data types with extension functions
(very hard to implement as I understand it), etc.

I suspect the 3rd option implementation challenge may not be as prohibitive
as it first appears. The design space seems larger than just "extend
arrays" versus "generic objects". I'm still exploring it though, so I'd
rather not jump to conclusions yet.

Cheers,
Michał Marcin Brzuchalski

[META] Weekly Internals Summary Videos

Tue, 21 Jul 2026 14:53:47 +0000

Hi Len,

First off, Great work, I appreciate your effort to glean more
visibility into the goings on in the internals of PHP and you have a nice
presentation style for your videos and a soothing voice.

Secondly, anything you read from me, simply refer to as fennic.

Hi contributors,

For the last 6 weeks or so, in an effort to make the PHP internals more
accessible and visible to a wider audience, I've been summarizing the
week's discussions into a ~10-15 minute weekly video, then breaking that
out into written content where it's supported, and threaded content for
other micro-blogging platforms.

I have two things to discuss:

I'm trying to ensure that contributors are properly
tagged/attributed/[at]mentioned on all these platforms, but I just don't
have a well built-out list of all of your social handles. I've collected
some of these from the internals Discord and through web searches, but it's
not enough. To collect these handles for platforms like LinkedIn, Reddit,
Twitter, Bsky, Threads, Mastodon, etc, would it make more sense for you all
to reply in this thread with all of your handles, or should I create a
simple Google Form and link that instead?

To maintain accuracy, I want to include publishing the video link here
to the internals list as part of my publishing workflow each week. I hope
this provides an easy path for anyone who feels I've misunderstood or
misrepresented their messages to correct me, allowing me to include a
'corrections and errata' segment in the videos. If we find that we're
having to do multiple corections each week, then I'll probably post the
first draft to the list and allow comments and corrections during an ~8hr
window before filming.

The data cutoff is weekly at 10pm Vancouver time (UTC-7) each Tuesday
evening. First draft of the script is usually ready by 11:30 PM, and
filming generally starts at 9:30am the subsequent Wednesday morning.
Publishing is usually finished around ~5pm that same Wednesday. I'm working
hard to speed this up, but it's an iterative process.

I'm going to include the link to last week's video here so that we can
address any necessary corrections, and I'll also a list of the platforms
where I posted it. If anyone has ideas for other platforms where this
visibility work might be appreciated, I'd love to know them. I've also been
submitting to laravel-news, and the phpweekly newsletter.

youtube https://youtu.be/cGNa33qGqEg
r/php
https://www.reddit.com/r/PHP/comments/1uxnmsp/this_week_in_php_internals_july_15_2026/
r/symfony
https://www.reddit.com/r/symfony/comments/1uxnuq0/this_week_in_php_internals_july_15_2026/
r/laravel
https://www.reddit.com/r/laravel/comments/1uxntqb/this_week_in_php_internals_july_15_2026/
dev.to
https://dev.to/projektgopher/this-week-in-php-internals-july-15-2026-4nhb
mastodon https://phpc.social/@ProjektGopher/116926982520569384
threads https://www.threads.com/@projektgopher/post/Da1bNf_lL-r
bsky https://bsky.app/profile/projektgopher.com/post/3mqq27xvmac2s
twitter https://x.com/ProjektGopher/status/2077559023998816461
linkedin
https://www.linkedin.com/feed/update/urn:li:share:7483325450434400256/

Thanks everyone for your help and support (especially on Discord), and I'm
eager to keep this thing going.

Cheers,
Len

You are going to include this email discussion in your video? right? :)

— Rob

[RFC] [VOTE] Minimum supported versions for PHP 8.6

Tue, 21 Jul 2026 13:51:08 +0000

I don't exactly understand why that Autoconf section does not mention
that
it is not available on distro levels for RHEL 8 and 9 so it makes
things
difficult for packagers like Remi who explicitly asked to delay it:

The proposal clearly specifies the minimum versions for various
distros.

Well but it's pretty confusing for voters because they don't know that
our
minimum target is RHEL 8 which we have been using for deciding about
minimum versions before. The fact that this even goes through RFC in
this

Depending on how you look at it, RHEL 8 is either already EOL or will
live until 2033. Halting all library upgrades for another 7 years is
neither in the interest of PHP users and maintainers.

form is not good because we should rather have a general policy about
minimum of supported distros that PHP is built on and set minimum deps
versions based on that. This just hides this fact and for voters that
have
no idea what the supported distro versions are as this is very hard to
notice.

As the RFC states, the autoconf requirement only affects builds from
git. The official releases from the PHP project include a ready-made
./configure script and thus do not require autoconf to build PHP. This
is similar to ext/uri and the uriparser dependency, where PHP bundles a
working version, but if you are unhappy with that, then you’ll need a
very recent version of the library that may not be provided on older
distros.

The question has been left unanswered. Since the only reply was a
vague
“I prefer to wait”, I proceeded with writing the RFC.

Well, that seems kind of clear to me that some possibility is there
otherwise there wouldn't be such preference.

From what I see and understand, the core RHEL 8 distribution only
provides PHP 7.2, any newer PHP version requires the use of external
repositories - or a custom build. If you don’t want to rely on the
PHP-provided ./configure script, then autoconf 2.71 would similarly be
available in external repositories (EPEL).

I consider being able to properly rely on C11 functionality to be
worth
it. Generally speaking, compilers on operating systems that don’t have
autoconf 2.71 likely also don’t (fully) support C11, the lack of a
modern autoconf is really just a canary there.

Do you have some specific problems and why does it need to be enforced
just
before the feature freeze and cannot wait longer?

I have various pending PRs to clean up custom implementations for things
that are guaranteed by C11. But these naturally require that we actually
can rely on C11 in practice with proper checks rather than an
easy-to-miss note in the documentation.

With regard to the timing, it was just convenient to bundle the two
upgrades together and I relied on Eric to handle the RFC stuff. Given
that it's cleanup-only and the first Alphas have already been released,
I'd be okay with delaying the merge of the autoconf upgrade for (early)
PHP 8.7.

Best regards
Tim Düsterhus

[RFC] [DISCUSSION] ext/gd 2.4 — codec sync, Gd\* OOP API, 2D vector/canvas

Tue, 21 Jul 2026 12:18:47 +0000

hi Rowan,

A quick side-note, a reply that opens with at least a hello goes a
long way. It costs nothing and it is the difference between a review
and a brush off. We are not bots and don't talk to bots.

Hi Pierre,

I apologise completely for this. I often forget to add a greeting when
editing a reply, particularly on mobile. I definitely do not want to
sound rude or inhuman, so I will try to remember to include this in future.

Can you clarify this point - what PR was this, and why did it need to be merged before even announcing the RFC?
I wonder why replying without actually reading the rfc and the linked
PR you asked about here linked in the RFC? or is there a particular
outcome expected?

I worded it that way to make sure I didn't look in the wrong place and
jump to the wrong conclusions. But the important part of the question
was the "why", which you have answered below.

However, to answer your question, It was important tot:

validate full compatibility of the libgd update with current php on
all platforms and supported features to date

it uses some "modern" C features, so a full blown validation on php
CIs is a must have first

Actual additions to php are thin layers now added in this thread
RFC. No more "business" logic in the binding itself but if needed to
handle older external versions.

That makes sense. I realise it's too late to say now, but it sounds like
the RFC text could have been presented in parallel to that
verification. That would have given more time for people to digest the
new user-facing API, and suggest any changes without running as close to
the feature freeze.

It's quite common for implementations not to be finalised even when an
RFC is voted on, as long as changes don't impact what was agreed in the
RFC. The policy that has been formalised explicitly allows for that to
happen during the Beta period.

This is a PR and RFC that massively improves existing functions. Read:
everything under the hood, aside from the new APIs, is fixes and
improvements to what already exists. The new APIs themselves have zero
impact on existing functionality. They prepare PHP 9 and bring a much
more developer friendly way to do image operations. And the recurring
answer, too many times, has been "policies" or "wiki syntax."

I understand your frustration, and from what I've read, it looks like a
really great addition to the language.

But I do think its important that new features are given the time and
attention needed to refine small details. Names of new keywords or
classes, signatures of new methods, etc, are generally very easy to
change during an RFC discussion, but very hard to change once it's made
it into a stable release.

On the other hand, it's useful to have a cut-off point for new features
somewhere in the release process. If an RFC is in discussion close to
that cut-off point, there's always going to be an awkward decision: do
we cut off discussion because we're running out of time for the release,
or do we push the feature back a year so we can have the proper discussion?

Although it feels like bureaucracy, having a pre-determined cut-off date
can in theory make that decision easier: we don't have to debate for
every RFC whether it's "small enough" or "important enough" to carry on
discussing, we just have to ask "is it ready in time for the cut-off?"

This release is still in alpha. Whatever the plan is for the next
beta, we're not at RC yet, and new approved features landing before RC
is exactly what we've reasonably expected before these non pragmatic
policies changes.

I'm not sure how strictly it was previously enforced, but the release
cycle update RFC from two years ago refers to the requirement for RFCs
to be voted before beta (but not necessarily merged) as an existing
policy: https://wiki.php.net/rfc/release_cycle_update

That RFC actually made that deadline later, because it shortened the
overall timeline, moving the feature freeze from July to August; and
thus the RFC discussion deadline from June to July.

Wherever that deadline falls, there will always be proposals which, for
whatever reason, are written close to it. Naturally, the authors of
those proposals will be frustrated at their change being held back until
the following year; but on its own, that's not a reason to ignore the
agreed cut-off date. Even if we allowed some discretion to land changes
after the deadline, it would need some justification - perhaps the RFC
is very small, or amends an existing RFC already in the release.

To me, a well-documented process feels fairer than making subjective
judgements on the worthiness of every RFC.

I will end, though, by saying I have no particular authority, and this
is all just my opinion. I wish you well, and look forward to digging
into your proposal, whichever release it ends up targeting.

Regards,

--
Rowan Tommins
[IMSoP]

[RFC] Typed array declarations

Tue, 21 Jul 2026 12:03:34 +0000

pon., 20 lip 2026 o 13:48 Wendell Adriel wendelladriel.ti@gmail.com
napisał(a):

Hey Michał,

This raises a broader architectural question:

Should Level 3 typed arrays rely on function-specific guards for these
APIs, or should internal APIs gradually move towards a model where the
result is built in a temporary zval and only assigned through a single
typed assignment after construction?

That approach would naturally preserve atomicity and would work not only
for list, but also for future typed arrays.

I'm not claiming this makes Level 3 impossible. Quite the opposite - I
think it highlights an implementation issue that any persistent refinement
over mutable arrays will eventually have to solve, regardless of whether
the refinement is list, array<T>, or something else.

I'd be interested to hear whether this has already been considered during
the design of Level 3, or whether this class of internal APIs simply hasn't
been explored yet.

This is very interesting.
I thought about it, but didn't dive too much into it.

However, from some checks I've done myself, when you say: "or should
internal APIs gradually move towards a model where the result is built in a
temporary zval and only assigned through a single typed assignment after
construction?"
That going into this direction would be very beneficial, however, I think
this would imply touching a lot of things that can have a broader impact.
If this is something that people would agree to follow, I think it would
be great.

I've been implementing a prototype of persistent list-typed properties

(where list is a structural refinement of array, i.e. array_is_list() must
always hold),

BTW, on this, is this already an RFC, or is the implementation somewhere
I can take a look at?

I actually moved away from the direction I originally suggested (adding
element constraints to arrays). I'm now exploring a separate approach based
on dedicated immutable value types, but it's still too early to discuss as
a concrete proposal. I'd rather wait until the design has stabilized.

Cheers,
Michał Marcin Brzuchalski

[RFC] Typed array declarations

Tue, 21 Jul 2026 09:12:13 +0000

Hey Larry,

I am opposed to this RFC, for all the reasons Rob mentioned. Moreover, I

don't believe the issues can be resolved by just waiting for the reified
generics RFC (which I really hope passes). The core issue is that PHP
arrays are an over-broad data structure, and we need to have a hard,
type-based (not just implied by generics) distinction between
lists/sequences, sets, and dictionaries/maps, the same way most languages
do.

There are a few ways that could be done: 3 generic objects (a la Kotlin,
my preferred approach), 3 generic objects with extension functions
(assuming we can get those), 3 new core data types with extension functions
(very hard to implement as I understand it), etc.

But tacking it onto the already-dangerously-overloaded array mega-type is
the wrong approach.

Thanks for the feedback.
I understand the concern of adding more things to the array type and I
think it's a valid concern.

Would you think that an RFC adding new types, maybe using Kotlin as a
reference (as you mentioned), for having strongly typed array/list
structures would be a better fit?
I'd be happy to propose and work on this if this would be a better
direction/approach.

---
Best Regards,
Wendell Adriel.
Software Engineer & Architect
https://wendelladriel.com https://wendelladriel.com