#externals

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Thu, 17 Sep 2026 23:30:41 +0000

I have noticed that my previous emails haven't received a response, and I
want to address this openly with everyone here.

I sincerely apologize for my recent behavior. As the first contributor from
Iran, reaching this point felt like overcoming impossible odds. Achieving
this level here is incredibly difficult—between the challenging educational
landscape, the lack of standard paths or certifications for PHP, and the
limited access to hands-on professional environments, getting to contribute
to the core is like climbing a mountain ten times over.

Because of this intense pressure, I lost my perspective. It was not my
intention to be difficult or aggressive. I ask you to please look at me
again as the Sepehr who first joined this community—eager and ready to
learn. I was wrong, and I am truly sorry.

Best regards,
Sepehr

[PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Thu, 17 Sep 2026 17:03:42 +0000

Curious what you and others think on whether this makes sense as an RFC
direction for 8.7, or if there are particular areas you would want
adjusted
first?

I don't understand much about the problem you're tackling, so I can't
meaningfully comment on if the API makes sense on a "high level" domain
specific perspective. However for the API to become a first class
citizen some changes will need to be made:

With the new polling API introducing the Io namespace, the
functionality should likely be provided as Io\Terminal. Grouping it
under Io makes sense to me and avoids reserving another top-level name.
Classes are not namespaces: Static methods that are not named
constructors should be free-standing functions. Thus
Io\Terminal\enable_ansi(), Io\Terminal\set_title(), etc. Alternatively
since they almost all seem to take the "file descriptor" as the first
argument, they could also be instance methods on an Io\Terminal\Terminal
class that receives the terminal handle in the constructor. I leave it
up to the domain experts to decide what makes more sense.
The enums should be unbacked. A backed enum is almost always the
wrong design decision, since there is rarely a single canonical and
obviously correct scalar representation.

Best regards
Tim Düsterhus

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Thu, 17 Sep 2026 16:11:58 +0000

Hi everyone,

Following the recent discussions, I have decided to withdraw the
array_str_contains RFC. I will be closing the corresponding PR shortly.

I would like to thank those who provided constructive feedback. I intend to
take some time to refine my approach and hope to contribute more useful
features and cleaner implementations to the project in the future.

Best regards,
Sepehr

[PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Thu, 17 Sep 2026 15:30:39 +0000

Ah got it, thanks for pointing out the 8.7 timeline Larry.

On the PECL to core transition, I personally lean toward sooner if people
see value in it, mostly so internals can help shape the API early before
conventions get locked in userland. For anyone curious to test or poke
around the code, the repository is here:
https://github.com/prateekbhujel/php-terminal
Any PRs, feedback, or design critiques are more than welcome.

Curious what you and others think on whether this makes sense as an RFC
direction for 8.7, or if there are particular areas you would want adjusted
first?

Pratik

[PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Thu, 17 Sep 2026 13:58:44 +0000

Hi Derick,

Wanted to share a quick update since June.

I ended up implementing your stream suggestions in the v0.6.0 and
v0.7.0 releases. All methods now accept native stream resources (like
STDIN, STDOUT, STDERR, and php:// streams) directly alongside the
enums. I also published it to Packagist, and installing through PIE
works cleanly now. I also added prebuilt Windows x64 DLLs to the
releases so folks on Windows can test without compiling from source.

My main motivation is still Windows CLI support. Tools like Laravel
Prompts and Symfony Console still drop into dumb text fallbacks on
Windows simply because core has no native raw mode or single key
reading primitives.

Now that the PIE package is working across Linux, macOS, and Windows, I
wanted to check if you think this is worth bringing up as an RFC for
8.5 or 8.6, or if it is better to keep gathering feedback through PIE
first?

Thanks,
Pratik

At this point it would be an RFC for 8.7, as 8.5 is already released and 8.6 is frozen.

As I've not used it yet I cannot speak to when an RFC would be appropriate. However, I will note that libraries moving from PECL to php-src in the past have often undergone changes in the process, so they're not a direct transfer/rename. Whether that is an argument to move it to core sooner or later I leave as an exercise for the reader. (I could likely argue either way, really.)

--Larry Garfield

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Thu, 17 Sep 2026 08:55:26 +0000

Hi everyone,

I’m writing this because I feel it’s important to address the recent
friction. First and foremost, I want to sincerely apologize to the whole
internals community, and specifically to Larry Garfield.

As an aspiring contributor from Iran, I didn't fully understand the
community norms, etiquette, and the weight of the processes here, which led
to some misunderstandings and behavior that I now realize was
inappropriate. I deeply regret any disruption I’ve caused to your valuable
time and workflow.

I genuinely care about PHP and the work you all do. I hope you can accept
my apology. I promise to step back, reflect, and learn from this. I want to
show that I am capable of being a respectful and constructive member of
this community.

Thank you for your patience and for hearing me out. I would appreciate it
if you could share your valuable feedback and advice on how I can improve
and move forward.

Best regards,
Sepehr

[PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Thu, 17 Sep 2026 04:49:43 +0000

Hi Derick,

Wanted to share a quick update since June.

I ended up implementing your stream suggestions in the v0.6.0 and v0.7.0
releases. All methods now accept native stream resources (like STDIN,
STDOUT, STDERR, and php:// streams) directly alongside the enums. I also
published it to Packagist, and installing through PIE works cleanly now. I
also added prebuilt Windows x64 DLLs to the releases so folks on Windows
can test without compiling from source.

My main motivation is still Windows CLI support. Tools like Laravel Prompts
and Symfony Console still drop into dumb text fallbacks on Windows simply
because core has no native raw mode or single key reading primitives.

Now that the PIE package is working across Linux, macOS, and Windows, I
wanted to check if you think this is worth bringing up as an RFC for 8.5 or
8.6, or if it is better to keep gathering feedback through PIE first?

Thanks,
Pratik

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 19:21:59 +0000

‪On Wed, 16 Sept 2026 at 15:19, ‫سپهر محمودی‬‎ sepehrphpr@gmail.com
wrote:

Does anyone here actually dislike my contributions to php-src????

Yes.

Yes from me as well. I don't know why you are persisting with this RFC. I
don't remember ever seeing so much mail in the list for such an unwanted
RFC.

I could understand if during the discussion stage, you got feedback like:
"OMG, I soooo need this." or "Finally! This has always been sorely missing
from the language." but that didn't happen. I hope you are not motivated to
contribute just so you can be considered a contributor. I hope ego or
prestige is not behind the unrelenting push.

Even if you can build a faster version in C, that doesn't mean it should be
added to the array_ functions family. I am sure dozens of callback
hybridized iterator functions could be written faster in C, but that is not
a green light to flood the core with more native functions.

As I mentioned previously, please silently compile your own list of
proposals. Once you have ~5 separate deeply-considered proposals that you
are proud of, then self-assess which is best and if it is worthy of
sharing. I have personally considered proposing array_transpose(),
preg_escape(), a PREG_ flag that omits unwanted full string matches,
making the third parameter of substr_replace() null by default to allow
suffixing an array of strings, and adopting .. range syntax across all
native functions which accept a character mask, but none of my arguments
feel like they would garner support. So, I'm keeping them locked away in my
mental vault. Maybe I'll have an epiphany that will make them attractive or
maybe they'll shape my thoughts on another idea. Not all ideas are winners,
that doesn't make someone a loser. Just keeping learning and growing.

Sincerely,
mickmackusa

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 15:22:04 +0000

Hi Sepehr

I sent personal mail.
Please check it.

Regards
Yuya

--

Yuya Hamada (tekimen)

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 14:48:05 +0000

‪On Wed, 16 Sept 2026 at 15:19, ‫سپهر محمودی‬‎ sepehrphpr@gmail.com wrote:

Does anyone here actually dislike my contributions to php-src????

Yes.

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 14:46:28 +0000

Second, my RFC page has received a significant number of views,

How can you tell? Considering the wiki software doesn't record view counts.

cheers
Derick

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 14:19:32 +0000

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۶:۴۱ Larry Garfield <
larry@garfieldtech.com> نوشت:

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield
larry@garfieldtech.com نوشت:

Hi internals,

It has been 3 days now and no one has agreed on running the
benchmark tests for my function.

If there is no agreement on keeping the benchmarks within the next 2
days, the benchmarks will be completely canceled for my function.

I look forward to hearing your valuable feedback. Also, this thread
is not just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.

With respect,
Sepehr

I'm pretty sure the reason no one has looked at your benchmarks is no
one supports this function. I don't believe I've seen a single person
agree with you that it's useful. You have just been flooding the list with
messages assuming this function will be the greatest thing since sliced
bread, across multiple threads for no apparent reason. You've already been
advised, both on list and off, on an alternate approach for your specific
use case. It seems obvious to me that PHP-Internals is just not interested
in this functionality. Period.

Whether you're using AI or not, your posts are not helpful or
constructive and people are tired.

It's OK to have a proposal rejected. Even very experienced long time
contributors have ideas declined early on. It is part of the process, and
that's OK. Pushing and pushing and pushing after it's clear that it's not
going to happen is not a part of the process. It's just a waste of
everyone's time.

Please stop wasting everyone's time.

--Larry Garfield

Hi Larry,

I need to clarify a few points regarding your email. First, you
initially set providing benchmarks as a primary condition for this RFC.
Later, in private, you told me they weren't necessary. Now, claiming
that these benchmarks are invalid or non-existent completely
contradicts your own initial request.

This is an outright lie.

I previously stated that if your argument for a feature is performance,
then it needs benchmarks to demonstrate that performance.

Weeks later (a few days ago), you emailed me directly asking for help with
CI issues on your PR.

This was my response:

Hi Sepehr.

I... don't know why you're asking me for help on this. I am very open
that while I do a lot of design work for PHP, actually working on the
codebase is not something I'm good at. I barely manage to read a few parts
of it, and don't know the first thing about why FreeBSD builds or such
would die.

This would be a question better directed at the list, or just ask for help
on the PR itself.

That said, I am also not sure why you're still pushing for that function.
The feedback has been universally negative. I'd lay good money that the
RFC never passes, no matter what your benchmarks say. As I said weeks ago,
if your particular code base is such that this is your bottleneck, then
first congrats on having a very efficient application, and second, it's
time to write a tiny extension for just your project.

This is not saying "benchmarks aren't necessary," "benchmarks are
invalid," or "non-existent." It's saying "stop wasting your time and
everyone else's, no one wants your RFC." That is still what I am saying.
(And looking at the RFC on the wiki, I don't actually see benchmarks
listed.)

As for performance, I’ve already conducted a real-world usage analysis,
and the JSON results are documented in the RFC. They clearly show that
this function outperforms the alternatives you suggested.

The alternative I suggested, weeks ago and in the email above, is writing
your own tiny extension to provide the C function you have already
written. Its performance, whatever it is, should be identical regardless
of whether it's in stdlib or your own extension. Your response here is
completely inaccurate and grossly misrepresents my very clear statements on
the matter.

Given the documentation and the results, I cannot accept your
assessment that the benchmarks are invalid. The performance of this
function is proven.

Once again:

I never said they are invalid.

There are no benchmarks on the RFC listed on the RFC index page
(although the formatting is broken)

What I said is that no one is interested in this proposal, regardless
of its performance, so please stop wasting our time and yours.

If you are unable to engage honestly and without misrepresenting what
others have said on this topic, then please remove yourself from the
mailing list.

--Larry Garfield

Hi Larry,

First, I have to point out that you told me to ignore benchmarks because
this function had no place in the core, yet now you claim it was a
misunderstanding.

Second, my RFC page has received a significant number of views, which again
contradicts your point.

Third, please stop trying to use language that leads the conversation in
the wrong direction.

Everyone is reading this email, and I have one question:
Does anyone here actually dislike my contributions to php-src????

With great respect to everyone and Mr. Garfield,
Mahmoudi

Needs some clarification on static zend_string vs zend_new_interned_string (php internals).

Wed, 16 Sep 2026 13:59:40 +0000

Hi David,

On Wed, Sep 16, 2026 at 4:16 PM David Maye Kitenge david.maye@seigisoft.com
wrote:

Hello everyone,

My name is David. I'm working on the refactoring of a PHP extension from
"Zephir" language to a cleaner C language output.

I came across the fact that the extension uses a lot of "static"
zend_string. No I want to convert those static zend_string into the
intern string.

From what I read today based on PHP internal book website and PHP Source
online, calling a Zen's new interest string function create a string whose
value is registered into a hash table. And then on a request in it this or
that send interned string is then retrieved from the hash table instead of
creating a new Zen string. Apart from the fact that every every news and
intern strings have an immutable ref count.

My doubt is the following:

Does ref counting increments/decrements when you create a Zend string
using the static keyword?

static applies to the C variable, not the string’s reference-counting
behaviour. A string held in static zend_string *s is still normally
refcounted unless it is interned.

Assigning a new zend_string as interned zend_string, when the flag
"IS_Interned_STRING" (if I remember correctly), the string is kinda garbage
collected? (Do I need to free the string)?

An actually interned string is managed by Zend/OPcache. The string
copy/release helpers leave its refcount unchanged, and you should not free
it directly.

To convert an existing string you own:
s = zend_new_interned_string(s);
Store the returned pointer, and the function will release the original
string and return an existing interned one. Do not separately release the
old pointer.
But, you should still use zend_string_release(s) when finished with your
owned reference. It is a no-op for interned strings, but handles
non-interned results, which these APIs can return with OPcache during a
request.

For fixed extension strings needed across requests, initialize them during
normal module startup (MINIT):
s = zend_string_init_interned("example", sizeof("example") - 1, true);

Strings interned during a request are not necessarily permanent; storing
their pointer in a static variable does not extend their lifetime.

Regards,

Alex

Needs some clarification on static zend_string vs zend_new_interned_string (php internals).

Wed, 16 Sep 2026 13:09:41 +0000

Hello everyone,

My name is David. I'm working on the refactoring of a PHP extension from "Zephir" language to a cleaner C language output.

I came across the fact that the extension uses a lot of "static" zend_string. No I want to convert those static zend_string into the intern string.

From what I read today based on PHP internal book website and PHP Source online, calling a Zen's new interest string function create a string whose value is registered into a hash table. And then on a request in it this or that send interned string is then retrieved from the hash table instead of creating a new Zen string. Apart from the fact that every every news and intern strings have an immutable ref count.

My doubt is the following:

Does ref counting increments/decrements when you create a Zend string using the static keyword?
Assigning a new zend_string as interned zend_string, when the flag "IS_Interned_STRING" (if I remember correctly), the string is kinda garbage collected? (Do I need to free the string)?

Thanks for your support.
David.

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Wed, 16 Sep 2026 13:08:31 +0000

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield
larry@garfieldtech.com نوشت:

Hi internals,

It has been 3 days now and no one has agreed on running the benchmark tests for my function.

If there is no agreement on keeping the benchmarks within the next 2 days, the benchmarks will be completely canceled for my function.

I look forward to hearing your valuable feedback. Also, this thread is not just for the benchmarks of this function; you can share any valuable feedback or thoughts you have regarding my function in this thread.

With respect,
Sepehr

I'm pretty sure the reason no one has looked at your benchmarks is no one supports this function. I don't believe I've seen a single person agree with you that it's useful. You have just been flooding the list with messages assuming this function will be the greatest thing since sliced bread, across multiple threads for no apparent reason. You've already been advised, both on list and off, on an alternate approach for your specific use case. It seems obvious to me that PHP-Internals is just not interested in this functionality. Period.

Whether you're using AI or not, your posts are not helpful or constructive and people are tired.

It's OK to have a proposal rejected. Even very experienced long time contributors have ideas declined early on. It is part of the process, and that's OK. Pushing and pushing and pushing after it's clear that it's not going to happen is not a part of the process. It's just a waste of everyone's time.

Please stop wasting everyone's time.

--Larry Garfield

Hi Larry,

I need to clarify a few points regarding your email. First, you
initially set providing benchmarks as a primary condition for this RFC.
Later, in private, you told me they weren't necessary. Now, claiming
that these benchmarks are invalid or non-existent completely
contradicts your own initial request.

This is an outright lie.

I previously stated that if your argument for a feature is performance, then it needs benchmarks to demonstrate that performance.

Weeks later (a few days ago), you emailed me directly asking for help with CI issues on your PR.

This was my response:

Hi Sepehr.

I... don't know why you're asking me for help on this. I am very open that while I do a lot of design work for PHP, actually working on the codebase is not something I'm good at. I barely manage to read a few parts of it, and don't know the first thing about why FreeBSD builds or such would die.

This would be a question better directed at the list, or just ask for help on the PR itself.

That said, I am also not sure why you're still pushing for that function. The feedback has been universally negative. I'd lay good money that the RFC never passes, no matter what your benchmarks say. As I said weeks ago, if your particular code base is such that this is your bottleneck, then first congrats on having a very efficient application, and second, it's time to write a tiny extension for just your project.

This is not saying "benchmarks aren't necessary," "benchmarks are invalid," or "non-existent." It's saying "stop wasting your time and everyone else's, no one wants your RFC." That is still what I am saying. (And looking at the RFC on the wiki, I don't actually see benchmarks listed.)

As for performance, I’ve already conducted a real-world usage analysis,
and the JSON results are documented in the RFC. They clearly show that
this function outperforms the alternatives you suggested.

The alternative I suggested, weeks ago and in the email above, is writing your own tiny extension to provide the C function you have already written. Its performance, whatever it is, should be identical regardless of whether it's in stdlib or your own extension. Your response here is completely inaccurate and grossly misrepresents my very clear statements on the matter.

Given the documentation and the results, I cannot accept your
assessment that the benchmarks are invalid. The performance of this
function is proven.

Once again:

I never said they are invalid.
There are no benchmarks on the RFC listed on the RFC index page (although the formatting is broken)
What I said is that no one is interested in this proposal, regardless of its performance, so please stop wasting our time and yours.

If you are unable to engage honestly and without misrepresenting what others have said on this topic, then please remove yourself from the mailing list.

--Larry Garfield

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Wed, 16 Sep 2026 09:49:52 +0000

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۳:۰۴ Tim Düsterhus tim@bastelstu.be
نوشت:

Hi

I think you've read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it
because
you don't send more email to the thread. Maybe I don't have the English
skill to make it clear about what is planned and made.

No, I hadn't taken another look at the RFC yet. I also made it clear
that I had not given it much thought (due to time constraints). But my
schedule should not be a blocker for RFCs to proceed.

>

Content-wise I also don't agree with the decision to keep using

untyped
>

constants instead of enums, but didn't have the time to actually think

>
this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree
on this.

From what I see not much discussion has happened on that topic. It's
basically just David suggesting it (and me previously suggesting it in
private) and you declining the suggestion. I think we can find a
reasonable middle-ground that makes use of enums, while not precluding a
future redesign of the ext/intl API. I'll send those to the discussion
thread to keep it in a single place.

Best regards
Tim Düsterhus

Hi Tim,

Thanks for bringing this up. I completely welcome finding a reasonable
middle-ground.

My long-term plan is indeed to actively contribute to ext/intl (especially
aiming for PHP 8.7, where we can systematically modernize the extension
with proper namespaces, enums, and cleaner error handling).

I'd be glad to see your proposed middle-ground in the main discussion
thread, and we can definitely work together to align it so it fits both the
current RFC requirements and the future ext/intl roadmap.

Best regards,
Sepehr

[RFC] IntlRelativeDateTimeFormatter

Wed, 16 Sep 2026 09:49:40 +0000

For enums and namespaces: I kept class constants and the global Intl*
class name to stay
consistent with the existing ext/intl API, such as IntlDateFormatter,
IntlListFormatter
IntlNumberRangeFormatter, and IntlDatePatternGenerator. I don't want to
make
IntlRelativeDateTimeFormatter somehow special here just because this is
added later.
I agree that enums and namespaces would be nicer in isolation,
indeed. But,
introducing them for only this one formatter would make the API
inconsistent with the rest
of ext/intl.

As I had mentioned in the voting thread, I think there is a reasonable
middleground to be achieved here:

 final class IntlRelativeDateTimeFormatter
 {
     public function __construct(
         ?string $locale = null,
         IntlRelativeDateTimeFormatterStyle $style =

IntlRelativeDateTimeFormatterStyle::Long,
IntlRelativeDateTimeFormatterCapitalization
$capitalizationContext =
IntlRelativeDateTimeFormatterCapitalization::None,
?NumberFormatter $numberFormatter = null,
) {}

     public function format(int|float $offset,

IntlRelativeDateTimeFormatterUnit $unit): string|false {}

     public function formatNumeric(int|float $offset, int $unit):

string|false {}

     public function combineDateAndTime(string $relativeDate, string

$time): string|false {}

     public function getErrorCode(): int {}

     public function getErrorMessage(): string {}
 }

 enum IntlRelativeDateTimeFormatterStyle {
     case Long;
     case Short;
     case Narrow;
 }

 enum IntlRelativeDateTimeFormatterCapitalization {
     case None;
     case MiddleOfSentence;
     case BeginningOfSentence;
     case UiListAndMenu;
     case Standalone;
 }

 enum IntlRelativeDateTimeFormatterUnit {
     case Year;
     case Quarter;
     case Month;
     case Week;
     case Day;
     case Hour;
     case Minute;
     case Second;
     // ...
 }

The practical change for the users is just moving some separators
around:

 $formatter->format(-1, IntlRelativeDateTimeFormatter::UNIT_DAY)
 // becomes
 $formatter->format(-1, IntlRelativeDateTimeFormatterUnit::Day)

Basically the first component of the constant name moves in front of the
:: (and underscores are replaced by pascal case).

No namespaces are introduced, leaving a clean place for a redesigned
Intl API that doesn't just expose the ICU API as-is, but the main
benefits of using enums are preserved: Better discoverability and
autocompletion in IDEs. Cleaner documentation (it's possible to document
both the enum and the individual cases). Simplified input checks in the
internal implementation (error handling is implicitly provided by the
engine with the Z_PARAM_ENUM specifier).

I believe that users will value the clearer API signatures provided by
enums over the tiny inconsistency of placing the “Unit”, “Style” and
“Capitalization” in front of the :: instead of after - and enums
themselves are already used in PHP’s stdlib (e.g. RoundingMode), so
users have already encountered them.

Best regards
Tim Düsterhus

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Wed, 16 Sep 2026 09:32:49 +0000

I think you've read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it
because
you don't send more email to the thread. Maybe I don't have the English
skill to make it clear about what is planned and made.

No, I hadn't taken another look at the RFC yet. I also made it clear
that I had not given it much thought (due to time constraints). But my
schedule should not be a blocker for RFCs to proceed.

>
Content-wise I also don't agree with the decision to keep using
untyped
>
constants instead of enums, but didn't have the time to actually think
>
this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree
on this.

From what I see not much discussion has happened on that topic. It's
basically just David suggesting it (and me previously suggesting it in
private) and you declining the suggestion. I think we can find a
reasonable middle-ground that makes use of enums, while not precluding a
future redesign of the ext/intl API. I'll send those to the discussion
thread to keep it in a single place.

Best regards
Tim Düsterhus

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Tue, 15 Sep 2026 23:05:25 +0000

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield <
larry@garfieldtech.com> نوشت:

Hi internals,

It has been 3 days now and no one has agreed on running the benchmark
tests for my function.

If there is no agreement on keeping the benchmarks within the next 2
days, the benchmarks will be completely canceled for my function.

I look forward to hearing your valuable feedback. Also, this thread is
not just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.

With respect,
Sepehr

I'm pretty sure the reason no one has looked at your benchmarks is no one
supports this function. I don't believe I've seen a single person agree
with you that it's useful. You have just been flooding the list with
messages assuming this function will be the greatest thing since sliced
bread, across multiple threads for no apparent reason. You've already been
advised, both on list and off, on an alternate approach for your specific
use case. It seems obvious to me that PHP-Internals is just not interested
in this functionality. Period.

Whether you're using AI or not, your posts are not helpful or constructive
and people are tired.

It's OK to have a proposal rejected. Even very experienced long time
contributors have ideas declined early on. It is part of the process, and
that's OK. Pushing and pushing and pushing after it's clear that it's not
going to happen is not a part of the process. It's just a waste of
everyone's time.

Please stop wasting everyone's time.

--Larry Garfield

Hi Larry,

I need to clarify a few points regarding your email. First, you initially
set providing benchmarks as a primary condition for this RFC. Later, in
private, you told me they weren't necessary. Now, claiming that these
benchmarks are invalid or non-existent completely contradicts your own
initial request.

As for performance, I’ve already conducted a real-world usage analysis, and
the JSON results are documented in the RFC. They clearly show that this
function outperforms the alternatives you suggested.

Given the documentation and the results, I cannot accept your assessment
that the benchmarks are invalid. The performance of this function is proven.

Regards,
Sepehr

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Tue, 15 Sep 2026 21:23:14 +0000

Hi internals,

It has been 3 days now and no one has agreed on running the benchmark tests for my function.

If there is no agreement on keeping the benchmarks within the next 2 days, the benchmarks will be completely canceled for my function.

I look forward to hearing your valuable feedback. Also, this thread is not just for the benchmarks of this function; you can share any valuable feedback or thoughts you have regarding my function in this thread.

With respect,
Sepehr

I'm pretty sure the reason no one has looked at your benchmarks is no one supports this function. I don't believe I've seen a single person agree with you that it's useful. You have just been flooding the list with messages assuming this function will be the greatest thing since sliced bread, across multiple threads for no apparent reason. You've already been advised, both on list and off, on an alternate approach for your specific use case. It seems obvious to me that PHP-Internals is just not interested in this functionality. Period.

Whether you're using AI or not, your posts are not helpful or constructive and people are tired.

It's OK to have a proposal rejected. Even very experienced long time contributors have ideas declined early on. It is part of the process, and that's OK. Pushing and pushing and pushing after it's clear that it's not going to happen is not a part of the process. It's just a waste of everyone's time.

Please stop wasting everyone's time.

--Larry Garfield

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Tue, 15 Sep 2026 15:53:56 +0000

Hi internals,

It has been 3 days now and no one has agreed on running the benchmark
tests for my function.

If there is no agreement on keeping the benchmarks within the next 2 days,
the benchmarks will be completely canceled for my function.

I look forward to hearing your valuable feedback. Also, this thread is not
just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.

With respect,
Sepehr

RFC karma request

Tue, 15 Sep 2026 15:24:52 +0000

Hi all!

I created an account on wiki.php.net

Username: mnapoli

My plan is to create a RFC for https://github.com/php/php-src/pull/23558 (allowing runtime distributors to ship a single binary for both CLI and FPM)

My GitHub profile: https://github.com/mnapoli/

Thank you!
Matthieu Napoli

Hello Matthieu,

If the primary concern is with size, it may make sense to instead look into creating a reusable shared library on unix, much like on Windows.

That being said, while I'm also in favour of shipping only one binary for both, I strongly believe that it should not become an opt-in that nobody ends up shipping. It should become default at the very least, with an option to explicitly disable cli/fpm sources to save a few kb in a 9mb+++ binary at most.

Have you had any thoughts about the embed shared library if fpm should also be exposed there?

Marc

Discussion on array_str_contains() RFC and performance benchmarking methodology

Tue, 15 Sep 2026 13:35:54 +0000

در تاریخ سه‌شنبه ۱۵ سپتامبر ۲۰۲۶، ۱۴:۴۴ Derick Rethans derick@php.net
نوشت:

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۱۵:۳۷ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 20:40 ‫سپهر محمودی‬ sepehrphpr@gmail.com:‬

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two
critical issues:

The provided implementation does not even build in my
environment. It is scientifically impossible to derive any
performance conclusions from code that fails to compile.

Given your own admission of limited familiarity with the Zend
Engine internals, the methodology applied here lacks the necessary
technical rigor for a valid assessment.

I am more than willing to engage with constructive, reproducible,
and engine-aware performance analysis. However, as it stands, the
provided material is effectively contentless and does not offer a
basis for a technical evaluation.

PLEASE UNZIP ATTACHED FILE. YOUR CODE.

If you lack a solid grasp of Zend Engine internals and core data
structures like zval—which is the very backbone of PHP’s C runtime—it
feels like you are simply relying on an AI assistant rather than
technical understanding. Without mastering zval and Zend memory
handling, working at this level in C is effectively crippled.

To answer your question: I am testing this on high-end industrial
64-bit hardware, and your provided files still completely fail to
build.

Perhaps you should tell your AI to think a bit harder before
generating patches and benchmarks.

This was incredibly rude to say.

It is you with all the AI generated content wasting everybody's time.

The amount of new threads, new discussions, is exhausting the members of
this list. Especially because these discussions don't seem to be going
anywhere.

Consider this to be a warning if you want to continue to participate in
this list.

cheers,
Derick
(With his list-admin hat on)

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

Hello everyone,

Regarding my previous comments directed towards dear Yuya, I sincerely and
deeply apologize. This is not the appropriate venue for such remarks, and
it was unprofessional of me to speak that way to you all, whom I hold in
the highest regard as the giants of the PHP community.

I have sent a private email to dear Hamada to apologize, and he has kindly
accepted. Even Tim reached out to me privately to emphasize that this list
is not the place for such tension. I want to assure you and the entire
internals community that I will refrain from any further inflammatory or
inappropriate language.

Regarding the use of AI:
Several people have raised concerns about this on the list, and I would
like to provide some context:

Sometimes I repeat a word twice by mistake—does an AI make such human
errors? No, it doesn't.
To get all my CI checks to pass, I think I have manually pushed about 17
times so far. With AI, a task usually gets resolved in just 2 pushes.
AI can write code in 2 minutes, and if you give it the same code to
debug, it can analyze it and provide a fully working solution in about 5
minutes. Meanwhile, it took me 7 full days using PhpStorm to prepare all
the necessary files.
...

sepehr

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Tue, 15 Sep 2026 12:02:47 +0000

Hi,

> It's debatable if the latest changes in response to my email constitute
> a major or a minor change regarding the cooldown. However there was also
> no email that changes were made to the RFC text (only that some were
> planned), which is why I didn't recheck the RFC before the vote - and
> the intent to vote expired.

I think you've read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it because
you don't send more email to the thread. Maybe I don't have the English
skill to make it clear about what is planned and made.

Given this misunderstanding yes I will threat this as a major change and
revert the voting process.

> Content-wise I also don't agree with the decision to keep using untyped
> constants instead of enums, but didn't have the time to actually think
> this through or read the RFC in-depth.

I have discussed this with David in the discussion thread. We all agree on this.
However, using untyped constants is a convention to the extension. Every other
classes in the extension don't use enums. I'd suggest to add this in the future
scope so a extension-wide RFC can revisit this topic later. I don't want to make
this new class special to others at the sake of consistency.

Further, using namespaces is also preferred here.

> For these reasons I voted against the RFC.

Please let me know if you have further suggestions. After resolving it, I will
announce the cooldown period again. There is no need to rush anyways :)

Weilin Du

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Tue, 15 Sep 2026 11:33:49 +0000

I am excited to announce the start of the voting of
my latest RFC on the international extension!

It's debatable if the latest changes in response to my email constitute
a major or a minor change regarding the cooldown. However there was also
no email that changes were made to the RFC text (only that some were
planned), which is why I didn't recheck the RFC before the vote - and
the intent to vote expired.

Content-wise I also don't agree with the decision to keep using untyped
constants instead of enums, but didn't have the time to actually think
this through or read the RFC in-depth.

For these reasons I voted against the RFC.

Best regards
Tim Düsterhus

[VOTE] [RFC] IntlRelativeDateTimeFormatter

Tue, 15 Sep 2026 11:18:26 +0000

Hi internals!

I am excited to announce the start of the voting of
my latest RFC on the international extension!

discussion link: https://externals.io/message/132187
RFC: https://wiki.php.net/rfc/reldateformatter

The voting process will end at 2026-09-29 11:14:40 UTC.

Thanks,
Weilin Du

Discussion on array_str_contains() RFC and performance benchmarking methodology

Tue, 15 Sep 2026 11:14:22 +0000

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۱۵:۳۷ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 20:40 ‫سپهر محمودی‬ sepehrphpr@gmail.com:‬

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two
critical issues:

The provided implementation does not even build in my
environment. It is scientifically impossible to derive any
performance conclusions from code that fails to compile.

Given your own admission of limited familiarity with the Zend
Engine internals, the methodology applied here lacks the necessary
technical rigor for a valid assessment.

I am more than willing to engage with constructive, reproducible,
and engine-aware performance analysis. However, as it stands, the
provided material is effectively contentless and does not offer a
basis for a technical evaluation.

PLEASE UNZIP ATTACHED FILE. YOUR CODE.

If you lack a solid grasp of Zend Engine internals and core data
structures like zval—which is the very backbone of PHP’s C runtime—it
feels like you are simply relying on an AI assistant rather than
technical understanding. Without mastering zval and Zend memory
handling, working at this level in C is effectively crippled.

To answer your question: I am testing this on high-end industrial
64-bit hardware, and your provided files still completely fail to
build.

Perhaps you should tell your AI to think a bit harder before
generating patches and benchmarks.

This was incredibly rude to say.

It is you with all the AI generated content wasting everybody's time.

The amount of new threads, new discussions, is exhausting the members of
this list. Especially because these discussions don't seem to be going
anywhere.

Consider this to be a warning if you want to continue to participate in
this list.

cheers,
Derick
(With his list-admin hat on)

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

[RFC] End PEAR Project Endorsement

Mon, 14 Sep 2026 20:39:02 +0000

Hey,

Hey Jakub,

Shouldn't we first unbundle it from php-src and then move to the
static archive or is the pear install (which I think is used in
Windows build in some cases) still work?

I plan to resume the work on that PR in October or November when I
should have more time but it would be good if someone could check if
that move to static archive cannot break anything in php-src.

With help from Derick I looked into it, my understanding is that we can
flip the switch without first unbundling as long as we don't break the
resource URLs (XML, packages, phars). The static archive will keep
providing the required resources under pear.php.net/*
http://pear.php.net/* (eg.
go-pear.phar) and pear.php.net/rest/* http://pear.php.net/rest/*;
just no longer from the
dynamic code base that powers the website currently. The domain will not
change.

That said, the vote -- depending on when it starts -- will not end
before mid October. The current archive is still PoC, and I will have
some work before switching. Realistically, we will not land anything
before November. So that aligns with your own timeline and we will have
time to coordinate. Sounds good?

Sounds good, thanks

Also related: Daniel recently opened
https://github.com/php/php-src/pull/23634 which targets 8.2.

I'm aware - we were just discussing it between RM's

Kind regards,

Jakub

[RFC] End PEAR Project Endorsement

Mon, 14 Sep 2026 16:31:54 +0000

Hey Jakub,

Shouldn't we first unbundle it from php-src and then move to the
static archive or is the pear install (which I think is used in
Windows build in some cases) still work?

I plan to resume the work on that PR in October or November when I
should have more time but it would be good if someone could check if
that move to static archive cannot break anything in php-src.

With help from Derick I looked into it, my understanding is that we can
flip the switch without first unbundling as long as we don't break the
resource URLs (XML, packages, phars). The static archive will keep
providing the required resources under pear.php.net/* (eg.
go-pear.phar) and pear.php.net/rest/*; just no longer from the
dynamic code base that powers the website currently. The domain will not
change.

That said, the vote -- depending on when it starts -- will not end
before mid October. The current archive is still PoC, and I will have
some work before switching. Realistically, we will not land anything
before November. So that aligns with your own timeline and we will have
time to coordinate. Sounds good?

Also related: Daniel recently opened
https://github.com/php/php-src/pull/23634 which targets 8.2.

Cheers
Nick

RFC karma request

Mon, 14 Sep 2026 13:23:23 +0000

Hi Matthieu

I created an account on wiki.php.net

Username: mnapoli

My plan is to create a RFC for https://github.com/php/php-src/pull/23558 (allowing runtime distributors to ship a single binary for both CLI and FPM)

My GitHub profile: https://github.com/mnapoli/

RFC karma was granted. Good luck!

Ilija

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 14 Sep 2026 12:56:02 +0000

Hi Tim,

Am 04.09.2026 um 19:51 schrieb Tim Düsterhus:

I disagree with the behavior of not wrapping Exceptions thrown in
user callbacks: I believe the correct choice is to throw a
\PregException with the Exception thrown in the callback as the
->previous exception. Not wrapping the user callback exception means
that one needs a catch(Exception) with a try just around the preg_
call to reliably handle all errors during regular expression
execution, which nullifies much of the benefit of having a dedicated
exception class in the first place.

It also violates the exception policy in
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables,
which states:

If an extension uses external functionality that may throw an
exception it MUST wrap any exception thrown by that functionality
into an appropriate exception of its own. It MUST set the $previous
property to the original exception when doing so.

Following the principle of least surprise, i would expect that this code:

try {
preg_replace_callback($pattern, $callback, $subject);
} catch (ValidationException $e) {
// Handle it
}

can be changed to the following, and still work like expected:

try {
preg_replace_callback($pattern, $callback, $subject, flags:
PREG_THROW_ON_ERROR);
} catch (ValidationException $e) {
// Handle it
}

When PREG wraps everything thrown in a user supplied callback into an
PregException, above code would no longer work.
Instead, we would need this:

try {
    preg_replace_callback($pattern, $callback, $subject, flags:
PREG_THROW_ON_ERROR);
} catch (PregException $e) {
    if ($e->getPrevious() instanceof ValidationException) {
        // Handle it
    } else {
        throw $e; // Rethrow if it wasn't the one we expected
    }
}

The policy states: "If an extension uses external functionality"
I would argue, that this should only target exceptions from the
extension's own external dependencies. As a user i do not care about
internal implementation details of an extension. In fact, it would be
surprising to the caller to face foreign exceptions. Therefore it makes
sense for any extension to catch those and wrap them in their own
exception hierarchy.

However, i would not regard user supplied callbacks to fall under that
policy rule. The extension itself is not using that code and knows
nothing about it. It just calls it, following the "Inversion of Control"
principle back into userland.

As always, a good indicator for questions like this is to check what
other languages are doing.

In Javascript, the Exception propagates untouched:

class MyError extends Error {}

const text = "test";

try {
text.replace(/.+/g, (match) => {
throw new MyError("User error");
});
} catch (error) {
console.log(error instanceof MyError); // true
}

Same in Python:

import re

def my_callback(match):
raise ValueError("User exception")

try:
re.sub(r'\d+', my_callback, "test")
except ValueError as e:
print("Caught user exception")

And while i didn't confirm it by running code myself, my research
pointed to Java, C#, C++, Rust and Ruby doing the same thing.

So it seems to me, it is standard convention in most popular languages
to let user exceptions propagate transparent.
PHP would be an outlier, if it started wrapping them inside
PregException. I don't think this would be the right call.

Regards,

Sascha

Freitags habe ich immer frei: Wir arbeiten bei F&P in einer
4-Tage-Woche. #32istdasneue40

F&P ♡ Creating Communities

https://www.fp.de
https://www.linkedin.com/company/f&p-gmbh-feig-&-partner/
https://www.instagram.com/fp_creating_communities/
https://www.kununu.com/de/fundp
F&P GmbH

Feldstraße 53
95152 Selbitz

Tel. 09280 - 98 11 18 - 0

Sitz der Gesellschaft: Feldstraße 53, 95152
Selbitz
Geschäftsführer: Dr. Ingmar Ackermann, Frank Noack
Amtsgericht Hof,
HRB 3352

RFC karma request

Mon, 14 Sep 2026 12:32:03 +0000

Hi all!

I created an account on wiki.php.net

Username: mnapoli

My plan is to create a RFC for https://github.com/php/php-src/pull/23558 (allowing runtime distributors to ship a single binary for both CLI and FPM)

My GitHub profile: https://github.com/mnapoli/

Thank you!
Matthieu Napoli

[RFC] End PEAR Project Endorsement

Mon, 14 Sep 2026 11:57:02 +0000

Hi,

Hey internals,

I would like to open the discussion to "End PEAR Project Endorsement":
https://wiki.php.net/rfc/end_pear_endorsement

Shouldn't we first unbundle it from php-src and then move to the static
archive or is the pear install (which I think is used in Windows build in
some cases) still work?

I plan to resume the work on that PR in October or November when I should
have more time but it would be good if someone could check if that move to
static archive cannot break anything in php-src.

Kind regards,

Jakub

[RFC] End PEAR Project Endorsement

Mon, 14 Sep 2026 11:18:18 +0000

Additionally, there is another good news. Chuck from PEAR made an
effort to recover the missing bug pages and was successful.
Thankfully, he now can and will provide us with everything we need for
the archive.

That's amazing news and very very welcome! Thank you for coordinating
with Chuck and thanks Chuck for unearthing the data!

Smile,
Juliette

PHP 8.6 Branch Cut - 1 Week Warning

Mon, 14 Sep 2026 09:13:40 +0000

Hi internals,

This is your one‑week warning for the PHP 8.6 branch cut.

Next Tuesday (September 22) we will create the PHP-8.6 branch as part of
the packaging of PHP 8.6.0RC1. At that point, master will move to PHP
8.7, and the default expectation will be that changes target PHP 8.7. If
patches need to be made against PHP 8.6, please ping the PHP 8.6 release
managers team for review.

The branch cut also marks the hard feature freeze: even features that do
not require an RFC can no longer be incorporated into PHP 8.6 and will
need to wait for a future release.

For those of us with karma, the merge workflow for bug fixes will change
after the branch cut: PHP-8.5 will get merged into PHP-8.6, and PHP-8.6
into master. Please keep an eye on GitHub when merging bug fixes to
ensure they land on the correct branches.

--
Your PHP 8.6 RM team,
Matteo Beccati, Joe Ferguson, and Daniel Scherzer

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Mon, 14 Sep 2026 08:34:37 +0000

در تاریخ دوشنبه ۱۴ سپتامبر ۲۰۲۶، ۱۰:۱۲ Tim Düsterhus tim@bastelstu.be
نوشت:

Hi

Following recent discussions regarding performance benchmarking
methodology
for the array_str_contains proposal, the benchmark tests have been
removed
to better align with the feedback received on the project's testing
scope
and requirements.

Can you please keep all the discussion and updates related to your RFC
within the same official discussion thread? Creating new threads for
everything makes it much harder for users to find what opinions and
changes went into the RFC, since there is no link between them.

Best regards
Tim Düsterhus

Hi everyone,

Due to some technical issues, the previous email thread is no longer
accessible. To follow the recommendation of keeping all discussions in a
single, official thread, we will be continuing the conversation regarding
the array_str_contains() RFC here.

Looking forward to your feedback and continuing the discussion in this
thread.

Best regards,
Sepehr

Fwd: PHP feature suggestion (static property data access)

Mon, 14 Sep 2026 06:52:03 +0000

Hey Vilius,

My suggestions would be to create something similar for class
properties f.e.
*MyClass::properties::name *could return "name" or some built-in meta
data object of that property containing more information(type,
nullable, public/private etc.).
...
Let me know what you think. I could spend some time defining more
specific documentation of how I would solve it, maybe write and RFC.
My first idea was to write you, maybe there is similar ideas already
reached you.

Maybe you want to check out
https://news-web.php.net/php.internals/120256 -- it's been discussed
under this proposal, and likely has some helpful context.

Cheers
Nick

Account verification

Mon, 14 Sep 2026 06:44:13 +0000

I recently registered an account on wiki.php.net.

Username: mahdi

As requested in the registration form, I am sending this email to
confirm
that I am a human, not a bot. I have 12 years of experience as a PHP
developer.

Welcome! Can you please shortly explain what you are planning to do with
your account? Do you have an RFC planned or a PR ready?

Best regards
Tim Düsterhus

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Mon, 14 Sep 2026 06:42:47 +0000

Following recent discussions regarding performance benchmarking
methodology
for the array_str_contains proposal, the benchmark tests have been
removed
to better align with the feedback received on the project's testing
scope
and requirements.

Can you please keep all the discussion and updates related to your RFC
within the same official discussion thread? Creating new threads for
everything makes it much harder for users to find what opinions and
changes went into the RFC, since there is no link between them.

Best regards
Tim Düsterhus

Fwd: PHP feature suggestion (static property data access)

Mon, 14 Sep 2026 06:03:09 +0000

Hello,

I am writing with PHP feature suggestion, regarding static information
about class properties.

Now in PHP there's a feature feature letting you access full class name
statically (getting static class name via MyClass::class).
It's very minimalistic but even that allows users to have one single point
of truth for full class name.

My suggestions would be to create something similar for class properties
f.e.
*MyClass::properties::name *could return "name" or some built-in meta data
object of that property containing more information(type, nullable,
public/private etc.).

As weird as it sounds - even returning the same "name" value would let IDE
and libraries to get information more statically.
There are plenty of libraries that asks developers to use field names as
strings. For example - Doctrine ORM, you need field names when defining
relations or generating DQL queries. For classes you are using ::class
syntax, but for fields you need to hardcode string values that are pain to
refactor later on or to run static analysis.

I understand that whole idea is kind of abstract but I am sure that a lot
of PHP developers who are targeting to write cleaner code would approve of
something similar to this to help reduce hardcoded value in their code.

Let me know what you think. I could spend some time defining more specific
documentation of how I would solve it, maybe write and RFC. My first idea
was to write you, maybe there is similar ideas already reached you.

Vilius Buividavičius

[RFC] End PEAR Project Endorsement

Mon, 14 Sep 2026 04:14:16 +0000

Hey everyone,

However, there is one detail I would want to double check with you
all. The RFC currently has this sentence:

Attempts to find solutions with PEAR maintainers, directly and
through official channels, did not lead to results.

Given that Chuck now got in touch and is in favour, I am not happy
leaving this sentence unchanged in the RFC. I'd much rather remove it
(or strike it and amend the agreement?).

I made the following changes to the RFC:

Removed the mentioned sentence and added a section to reflect the new
situation.
Removed "Future Scope" and added explicit timeline to the proposal
(coordinated with Derick).

This is a major change, which means the discussion remains open until at
least 2026-09-27.

Additionally, there is another good news. Chuck from PEAR made an effort
to recover the missing bug pages and was successful. Thankfully, he now
can and will provide us with everything we need for the archive.

Cheers
Nick

[RFC Update] array_str_contains(): Removal of performance benchmark tests

Sun, 13 Sep 2026 19:40:23 +0000

Following recent discussions regarding performance benchmarking methodology
for the array_str_contains proposal, the benchmark tests have been removed
to better align with the feedback received on the project's testing scope
and requirements.

EBNF

Sun, 13 Sep 2026 08:40:32 +0000

Dear internals

After enviously looking at pythons grammar
(http://docs.python.org/dev/reference/grammar.html) I keep feeling
that PHP is missing out on a lot of interesting meta projects by not
having an official EBNF.

Building your own PHP parser is very hard and is PhD (Paul Biggar:)
level stuff if you wan't to get all the edge cases right. Having the
official EBNF would make this easier.

I know there is a lot of historical reasons for this and that creating
and maintaing said EBNF is a very serious task, one that is maybe too
big for a non-paying open source project.

But still I have to ask if I'm the only one thinking about this or is
there something I'm being completely ignorant about?

Happy newyear!
Rune Kaagaard

I see this post is already 15 years old, but having a well defined EBNF
grammar for PHP would invaluable for 3rd party tool designers.

We have just recently completed the first EBNF mapping for PHP 8.5 from
source code, and plan to also map all future versions of PHP. I

If there is enough interest we will also consider mapping older versions
of PHP.

You can browse, and download the EBNF in machine-readable and human
reabile format from this website:
https://zoclee.com/php-grammar

or from the GitHub repository at
https://github.com/zoclee/php-grammar

--
{Zoclee}

Kind regards,

Alwyn Bester

Account verification

Sat, 12 Sep 2026 18:51:23 +0000

Hello,

I recently registered an account on wiki.php.net.

Username: mahdi

As requested in the registration form, I am sending this email to confirm
that I am a human, not a bot. I have 12 years of experience as a PHP
developer.

You can view my GitHub profile here: https://github.com/MahdiAkrami01

Thank you. Regards

php-grammar: source-backed EBNF grammar for PHP

Sat, 12 Sep 2026 17:50:27 +0000

Hi all,

I’d like to make the PHP development community aware of a project I’ve
been working on called php-grammar.

The project provides versioned, source-backed EBNF grammar definitions
for PHP language syntax, together with matching human-readable
documentation.

The current PHP 8.5 grammar has been developed and audited against the
PHP parser source, with the goal of representing the language syntax as
accurately and completely as possible while keeping the grammar useful
to tooling authors and other consumers.

The project is independent and is not presented as an official PHP
specification. My main reason for posting here is to invite technical
review from people familiar with the PHP parser and language implementation.

In particular, I’d be very interested in feedback on:

places where the EBNF does not accurately represent parser behaviour;
syntax that cannot reasonably be represented in pure EBNF without
additional semantic restrictions;
contextual or parser-specific constraints that should be documented
more clearly; and
whether the overall approach could be useful to parser, IDE,
documentation, static-analysis, or other tooling projects.

Website:
https://zoclee.com/php-grammar https://zoclee.com/php-grammar

GitHub:
https://github.com/Zoclee/php-grammar

Any corrections, criticism, or suggestions would be very welcome.

--
{Zoclee}

Kind regards,

Alwyn Bester
Founder and CEO

Architectural discussion: Composable functional patterns vs. specialized native functions in PHP's standard library

Sat, 12 Sep 2026 00:50:09 +0000

در تاریخ شنبه ۱۲ سپتامبر ۲۰۲۶، ۰۳:۱۹ Kamil Tekiela tekiela246@gmail.com
نوشت:

Hi Sepehr,

I believe discussing these fundamental trade-offs will help provide
clearer guidelines for future RFC proposals and the continuous evolution of
PHP's standard library.

What are you trying to accomplish with this discussion? What is the
goal? I am asking because I don't quite understand your questions, and
this whole topic seems very vague. What are these clearer guidelines?

Over recent major versions, modern PHP has embraced functional
programming idioms with first-class callable syntax, arrow functions, and
generic higher-order operations. While this compositional style
significantly enhances code expressiveness and flexibility, it introduces
notable architectural considerations:

I would never consider first-class callables or arrow functions to be
functional programming idioms. Sure, higher-order functions are
heavily used in functional programming, but they are just as useful in
object-oriented programming or procedural programming.

Performance & Engine Overhead:
When composing generic higher-order utilities (such as array/string
transformers, filters, and mapping operations), what is the acceptable
threshold for closure invocation overhead and VM context switching in
performance-critical paths? In what scenarios do we consider this overhead
significant enough to warrant dedicated, low-level C implementations in the
engine?

I don't know if that has ever been a major consideration. We consider
performance on a case-by-case basis. Just like with your recent
proposal, we ask for some hard evidence. How often is it causing a
performance bottleneck in real projects? What kind of performance
improvement would be expected if it were a dedicated function? Etc.

PHP has traditionally provided rich, specialized functions for common
data manipulation tasks. How do we balance keeping the standard library
lean and orthogonal versus providing high-utility, specialized native
functions that eliminate recurring boilerplate across userland applications?

PHP has never been known as a good example in this regard. The
standard library is a complete mess (everything but a kitchen sink).
In recent years, the consensus has been that we only add functions
that provide behaviour which is either impossible or very difficult to
emulate in userland, or so ubiquitous that it deserves a dedicated
function. For example, str_contains was added to simplify strpos !== false, array_first was added to simplify
$array[array_key_first($array)], array_is_list was added to expose
functionality which was quite difficult to emulate in userland. All of
these are examples of very common patterns that were used verbatim
sometimes hundreds of times in a single project.

Performance Benchmarking & JIT Optimization:
As the JIT compiler matures, should the engine rely more heavily on JIT
optimizations to inline higher-order functional patterns, or will
specialized native C functions always remain the preferred standard for
mission-critical operations?

JIT is only useful for highly specialised applications. For most
applications, such as websites, JIT doesn't offer a lot of benefits.
But besides that, I don't really understand this question. It seems
like a non-sequitur to me.

I won't even attempt to answer the last question, as it seems so vague
to me; one could write a whole book about it and still have more to
add.

Regards,
Kamil

Hi Kamil,

Thank you for the direct feedback. I appreciate you pointing out the
vagueness in my initial questions; that was not my intention, but I see now
that I was approaching the topic from too high an abstraction level.

To clarify my goal: I am not looking for a philosophical treatise, but
rather to understand the practical "threshold" the core team uses when
deciding whether a common pattern (like string searching within an array)
should be implemented as a specialized native function versus leaving it to
userland composition (like array_filter with a closure).

You mentioned that performance is considered on a case-by-case basis with
hard evidence. That is exactly where I want to focus.

Instead of discussing generalities, I will prepare a concrete benchmark. I
plan to compare:

The overhead of common compositional patterns (e.g., array_filter +
str_contains inside a closure).
The performance of a potential specialized native implementation (e.g.,
a hypothetical array_str_contains).

My goal is to provide the "hard evidence" you mentioned, showing
specifically where the overhead of closure invocation and VM context
switching becomes a measurable bottleneck in common real-world scenarios.

I will follow up with the results once the benchmarking is complete.

Regards,
Sepehr

Architectural discussion: Composable functional patterns vs. specialized native functions in PHP's standard library

Fri, 11 Sep 2026 23:49:05 +0000

Hi Sepehr,

I believe discussing these fundamental trade-offs will help provide clearer guidelines for future RFC proposals and the continuous evolution of PHP's standard library.

What are you trying to accomplish with this discussion? What is the
goal? I am asking because I don't quite understand your questions, and
this whole topic seems very vague. What are these clearer guidelines?

Over recent major versions, modern PHP has embraced functional programming idioms with first-class callable syntax, arrow functions, and generic higher-order operations. While this compositional style significantly enhances code expressiveness and flexibility, it introduces notable architectural considerations:

I would never consider first-class callables or arrow functions to be
functional programming idioms. Sure, higher-order functions are
heavily used in functional programming, but they are just as useful in
object-oriented programming or procedural programming.

Performance & Engine Overhead:
When composing generic higher-order utilities (such as array/string transformers, filters, and mapping operations), what is the acceptable threshold for closure invocation overhead and VM context switching in performance-critical paths? In what scenarios do we consider this overhead significant enough to warrant dedicated, low-level C implementations in the engine?

I don't know if that has ever been a major consideration. We consider
performance on a case-by-case basis. Just like with your recent
proposal, we ask for some hard evidence. How often is it causing a
performance bottleneck in real projects? What kind of performance
improvement would be expected if it were a dedicated function? Etc.

PHP has traditionally provided rich, specialized functions for common data manipulation tasks. How do we balance keeping the standard library lean and orthogonal versus providing high-utility, specialized native functions that eliminate recurring boilerplate across userland applications?

PHP has never been known as a good example in this regard. The
standard library is a complete mess (everything but a kitchen sink).
In recent years, the consensus has been that we only add functions
that provide behaviour which is either impossible or very difficult to
emulate in userland, or so ubiquitous that it deserves a dedicated
function. For example, str_contains was added to simplify strpos !== false, array_first was added to simplify
$array[array_key_first($array)], array_is_list was added to expose
functionality which was quite difficult to emulate in userland. All of
these are examples of very common patterns that were used verbatim
sometimes hundreds of times in a single project.

Performance Benchmarking & JIT Optimization:
As the JIT compiler matures, should the engine rely more heavily on JIT optimizations to inline higher-order functional patterns, or will specialized native C functions always remain the preferred standard for mission-critical operations?

JIT is only useful for highly specialised applications. For most
applications, such as websites, JIT doesn't offer a lot of benefits.
But besides that, I don't really understand this question. It seems
like a non-sequitur to me.

I won't even attempt to answer the last question, as it seems so vague
to me; one could write a whole book about it and still have more to
add.

Regards,
Kamil

Architectural discussion: Composable functional patterns vs. specialized native functions in PHP's standard library

Fri, 11 Sep 2026 23:08:59 +0000

Hi everyone,

I would like to open a broader technical discussion regarding the long-term
design philosophy of PHP's standard library, specifically focusing on the
trade-offs between composable higher-order functions and dedicated native
engine functions.

Over recent major versions, modern PHP has embraced functional programming
idioms with first-class callable syntax, arrow functions, and generic
higher-order operations. While this compositional style significantly
enhances code expressiveness and flexibility, it introduces notable
architectural considerations:

Performance & Engine Overhead:
When composing generic higher-order utilities (such as array/string
transformers, filters, and mapping operations), what is the acceptable
threshold for closure invocation overhead and VM context switching in
performance-critical paths? In what scenarios do we consider this overhead
significant enough to warrant dedicated, low-level C implementations in the
engine?
Standard Library Cohesion & API Surface:
PHP has traditionally provided rich, specialized functions for common data
manipulation tasks. How do we balance keeping the standard library lean and
orthogonal versus providing high-utility, specialized native functions that
eliminate recurring boilerplate across userland applications?
Performance Benchmarking & JIT Optimization:
As the JIT compiler matures, should the engine rely more heavily on JIT
optimizations to inline higher-order functional patterns, or will
specialized native C functions always remain the preferred standard for
mission-critical operations?
Edge Cases, Type Consistency & Encodings:
When designing or evolving standard functions across different data domains
(strings, arrays, multibyte handling, streams), what architectural
guidelines should we establish to ensure uniform behavior, strict typing
semantics, and consistent error handling across the entire API surface?

I believe discussing these fundamental trade-offs will help provide clearer
guidelines for future RFC proposals and the continuous evolution of PHP's
standard library.

I look forward to hearing your perspectives and insights.

Best regards,
Sepehr

PHP 8.6.0beta3 is available for testing

Thu, 10 Sep 2026 22:29:19 +0000

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

Or use the git tag: php-8.6.0beta3

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.0 RC1 should be expected in 2 weeks, i.e. on 24 Sep 2026.

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

Thank you, and happy testing!

Regards,
Matteo Beccati, Joe Ferguson & Daniel Scherzer

php-8.6.0beta3.tar.bz2
SHA256 hash:
e1517694d025b947430bc31afe41e6e134f68782d944542b962cf0b5132b1936
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXP8Xtk3BwkT10OrD5DU14usZAQ4FAmqgQm0ACgkQ5DU14usZ
AQ5MOw//YswpeEyRxHl7p23a25ppbdetos/rIABsGBA5mfyRSx7xqvbWyFt/Fjhd
Af8nN2rY8T7z4Wto6Q34fEzBCKpQZV23IM7spd89nBscJNG3HdtF5StYq4TFzg9W
O5eS5zsslwGGWTz/iESthjqD6fiPTfzJ/Qc9DbWN5pNee7E+55fnJ6suGG9G+J4m
g1M0v+vtWg3mmAsSIDJZ/Cnx6fuD2+nNYK31EwJot88J3TOQkiGnZN191zu0TjZG
2m6yAX6Nfuie+NvwWCUi8lYh6AaMIta148DAQQDcL0GoN0heDh1uTTK7gmEkgd0R
WWdtEQSWIN05/rCvm5eiL8BN945JQMBmmvFBjIac86to6WS35X0g7G7xVs79fuCZ
y6BmUAIyekpP+wMFEcytfjQT07mzlvtc58DHbpDTXF5/KHSP1jeiweQVR1DlxlRW
D/mColQiq9I3aaB5fH4U/z1HAUzDPsKh71tZvIFekgGJxz1afQPvrI68mJaQGBuu
zIQ/vWjahxXol8o0DA9K7h90orn5MkNOg8eRyyA8Zono6JT9FgLErSEn2I1hqGOM
VBWZuYpXgtLBTgfazg1FUxgAmJDadPvOdl3UwFyvvM+78VY/xBmvft5ep1QmfRC7
KF0rzzZNYjwoP33pJCyFz3YgHoXjm/0U2J5sskX71tkGu+nyR40=
=6MMD
-----END PGP SIGNATURE-----

php-8.6.0beta3.tar.gz
SHA256 hash:
2499bb217d77566319c0e971a36041484b8cb7181ef5adf282a751e132015e8c
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXP8Xtk3BwkT10OrD5DU14usZAQ4FAmqgQm0ACgkQ5DU14usZ
AQ4SYg//bLujzUXMuG5v9zHvfelOtlYxYT3eD2OuUtnZLLENi4+P+bLxCwj+Mk39
FztxJaAitUulrrARebAmVCCKX6o0nvCbA8jwB9i/tEeA4aGWevCRCKMBW7rlqZcH
v9mXgQkDI5Uaq4e53IsTuTsXJtQVkd1LgDad/R3Aq1o48Vs+KRNcfuJcyAopYvgd
Naph7iqAoUmlHotb7q46jtHJTq++IaKHhrKuQsdcUJWUYyYaYqXMeCaIvSPUp32l
OMjfUpLL99rp0QuTvX0LtVkfkY46aZtva52xVAtG7tkOpIT7pHnULRIpFuHDzpM9
2dRB6/u87Ph3cG/VirLdFiKKuaNxVCF7A0yaFooW4BMz4VLATRhOgVuLndFO3Ffb
OcxcHShnwJLH9BXut7P5dO4jIwrrpT5wbdt3mEQMppReGNhQ5rLSePdAeIJdMBdB
ao4NBhT2jNQmUwFdo1mjGdm2gQB2wq5BlPgavijDh0xBPHfWt9xveHN/m89w/Dnh
2z1XrqO4MEKPwHyJMyEj1KaPPSmdLedYuVkZi2DFf+DQoAVeAyHXyuPlf1Zx2kKB
8R7jV/7PTDA+9ygqxd6UamoWjAVRfDC1rFnQXQC5iElh2Pn5xThO2C6lCgJqttoY
7/uymG95+4dt8dPggwMhfBvWA4Eds/SZMGzv4OQTALfOhJJP7Og=
=Udya
-----END PGP SIGNATURE-----

php-8.6.0beta3.tar.xz
SHA256 hash:
e8daf9546c4d4244dad961b5412734db57823c2e967df3fcfbb819a62d520ea6
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXP8Xtk3BwkT10OrD5DU14usZAQ4FAmqgQm0ACgkQ5DU14usZ
AQ7gIQ//dlQyQiBO49FNrXqa/GjYTK9FBOynRt90D6rbeiH6MRg8arePKK9Pm1bF
Gulk4KQfH8kgS9fWyDswaA8ah00nK2n6GAH3wU1hpVskLcbMvuLugIvaMRefUcWS
UiwabWY3RiPhmkSeAXI+n43h3gbD955ZuwwfLmWNUMWmu0CSc7VGwI5yiYa0c2V4
6NxS0M8S7D/glhZSwEq02hVG2P9dBPg8HIdNQOO06lGt+/URV+G1uFqJl1jidNKn
SRRZZJH3OXOQBsqEZVVzf0vnWE3Dh5G/GQKdTV8FM1GfYCU3F8+rMj4pcC1+t8Y/
iLgnuu4tJ0FiHP0+dlca3Xck3AOe28S7qX616C4rm/XEA6rzVz8i0WAl2IWziwU4
VfLUtL20Xa4/0URiInhiYWQf6w/OK5OLGaMO3GRgPjHlF1SqaSu66+zZzTitn1hd
lNLMVLULju/r8+KUFlZOusdw5Rp6kfxbyApIw+EkcN4nVtCzHVxlYwC6lJCOPtNB
+kOScJ619mxv6odAuc6Oj9J/rxxZDfZw5P6eLEwCC2uGHNQBYzQybk0sjTWvMH6T
uY8Hskw4EDfIfrQL+AaC4QA0Nz9li2jC1/oo6c4Pn4q7f/BEwxM13Rf5BnsS3IrU
cFoGoNkfgNDRJbyN76+hAqlIfKFuckeuX9pBMKEJx7VIveTyKxk=
=FO9O
-----END PGP SIGNATURE

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 21:34:39 +0000

Hi everyone,

I would like to sincerely apologize to everyone, especially Yuya, for the
tension in our recent discussions. Moving forward, I would like to keep
this thread strictly focused on the technical merits of the proposed
function.

Larry, since you were the first to suggest this, I would like to ask for
your feedback: I have prepared a benchmark script and would like to include
it in the RFC so that everyone can run the tests themselves.

Also, I have cleaned up the C implementation for the function, and I would
appreciate it if you and the others could take a look at it.

Best regards,
Sepehr

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 21:14:56 +0000

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 20:07:00 +0000

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۲۱:۴۴ Juris Evertovskis juris@glaive.pro
نوشت:

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I've been following the discussions and recent feedback regarding the
array_str_contains() RFC closely. Performance and speed comparisons have
come up as a key point, especially around whether a dedicated internal C
implementation provides sufficient value compared to a userland foreach
loop.

I'd love to open up a constructive and transparent discussion around the
benchmarking methodology we're using here. Some of the initial numbers
shared recently don't seem to reflect real-world scenarios or different
data profiles (like varying array sizes, early exits vs worst-case lookups,
UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be
great if we could align on:

The exact benchmark scripts and test datasets we should use to
evaluate this fairly.

The compilation environment and flags used for generating these
metrics.

Where the potential overhead in the current C implementation is
coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for
everyday developers. I welcome any suggestions, insights, or benchmark
reproductions from the community so we can evaluate this RFC based on
solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff

.exp

.log

.out

.php

.phpt

.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi Internals,

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two critical
issues:

The provided implementation does not even build in my environment. It
is scientifically impossible to derive any performance conclusions from
code that fails to compile.

Given your own admission of limited familiarity with the Zend Engine
internals, the methodology applied here lacks the necessary technical rigor
for a valid assessment.

I am more than willing to engage with constructive, reproducible, and
engine-aware performance analysis. However, as it stands, the provided
material is effectively contentless and does not offer a basis for a
technical evaluation.

Best regards,

Sepehr

Hi Sepehr,

I've also been following the discussions on the mailing list.

My read is that Yuya has been the one most welcoming to you. He was
putting in a word for you during the discussion about message phrasing,
providing you some guidance and expressing willingness to involve you in
the i18n work. His openness is visible even now — unlike most of us, he is
trying out your code and giving you feedback.

Therefore it is a bit sad to see you being angry and dismissive at him in
the latest discussions. I think you are mistaking his short statements for
hostility or gatekeeping. My suggestion: stop throwing away his goodwill.
If an experienced contributor is giving you feedback, you should seriously
consider that there might be something true and useful.

Regarding the latest discussion I would like to add that admitting lack of
expertise in zend engine (or anything else) is usually not seen here as a
sign of weakness, but of honesty. Many of the readers and voters here are
not experts on every detail either. If someone admits not entirely
understanding what's going on, it gives you a chance to provide
explanations and proof instead of dismissing his benchmarks as useless.

By the way...

Just for your information: someone praised my work who holds a high
position in php-src and whom I truly respect—meaning your opinion doesn't
really matter to me.

Different open source communities may work differently, but in this one a
reference to an unnamed figure is unlikely to earn you additional respect
or authority. It's best to leave such statements out.

BR,
Juris

Hi Juris,

Thank you for taking the time to write this and share your perspective.

You make very fair points, and reading this helped me see things from a
better angle. I let my emotions get the better of me in that interaction
with Yuya, and I genuinely appreciate you pointing it out.

I will reach out to Yuya to clear the air, and I'll keep your advice in
mind moving forward. Thanks again for the constructive feedback.

Best regards,
Sepehr

PHP 8.5.11C1 available for testing

Thu, 10 Sep 2026 18:27:33 +0000

PHP 8.5.11RC1 has just been released and may be downloaded from
https://downloads.php.net/~edorian/

Or use the git tag: php-8.5.11RC1

Windows binaries are available at:
https://www.php.net/pre-release-builds.php?release=8.5.11RC1#windows

Please test it carefully and report any bugs at
https://github.com/php/php-src/issues

8.5.11 should be expected in 2 weeks, on 24 Sept 2026.

Hash values and PGP signatures can be found below or at
https://gist.github.com/edorian/4b08d5e2adbc3cebb1c5b8eed5988b25

Thank you, and happy testing!

Regards,
Volker Dusch, Daniel Scherzer, and Pierrick Charron

php-8.5.11RC1.tar.bz2
SHA256 hash: 24574eb0c8c1bceac833a5b984fcfb0cde50a019f6a757c35f28da3dc97300b9
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCaqAtEBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1KDf
AQDRBlaUzMBxo6g5P6z1G7Rzo5UqjjoXYVVblTK2/hhWNgEA0WYrv52DN7+zvWtb
YFPhxGiPvN3YKYVZw3jQMOvVYQQ=
=dsNV
-----END PGP SIGNATURE-----

php-8.5.11RC1.tar.gz
SHA256 hash: dd0a2dc233ee6dd6d8ef389b671fefc5cd0f49b859d16e53d875582c5e248bbb
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCaqAtEBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1PkJ
AQDF+GtyYlGes1JY4h1QFH7ite88BurShl/YzQ1aWG2VbQEA98w9iUZzc2WAOMTC
O9iL7E/7vusydH2KhwpL8xhhLgs=
=Ni4S
-----END PGP SIGNATURE-----

php-8.5.11RC1.tar.xz
SHA256 hash: 84e5d0abc91f6b1f69de6c5ec5d3720124582417c7ce6c5df742dcbada179a82
PGP signature:
-----BEGIN PGP SIGNATURE-----

iKIEABYKAEoWIQRJ2a9rxyqA1mkXGciqI/W+nHCX1AUCaqAtEBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMQHGVkb3JpYW5AcGhwLm5ldAAKCRCqI/W+nHCX1EtM
AP9ggAbvewtH/Dkckf9Brtv+ZKb2togcVomklKZZBIuStAD9HYKxkv43vSqz/UI6
L1zMTRBbjpwIzc+JxHLnY96hSgI=
=d7OJ
-----END PGP SIGNATURE

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 18:13:59 +0000

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai
youkidearitai@gmail.com نوشت:

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I've been following the discussions and recent feedback regarding the
array_str_contains() RFC closely. Performance and speed comparisons
have come up as a key point, especially around whether a dedicated
internal C implementation provides sufficient value compared to a
userland foreach loop.

I'd love to open up a constructive and transparent discussion around
the benchmarking methodology we're using here. Some of the initial
numbers shared recently don't seem to reflect real-world scenarios or
different data profiles (like varying array sizes, early exits vs
worst-case lookups, UTF-8 strings, and compiler optimization flags
like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be
great if we could align on:

The exact benchmark scripts and test datasets we should use to
evaluate this fairly.

The compilation environment and flags used for generating these
metrics.

Where the potential overhead in the current C implementation is
coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for
everyday developers. I welcome any suggestions, insights, or
benchmark reproductions from the community so we can evaluate this
RFC based on solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff

.exp

.log

.out

.php

.phpt

.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi Internals,

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two critical
issues:

The provided implementation does not even build in my environment.
It is scientifically impossible to derive any performance conclusions
from code that fails to compile.

Given your own admission of limited familiarity with the Zend Engine
internals, the methodology applied here lacks the necessary technical
rigor for a valid assessment.

I am more than willing to engage with constructive, reproducible, and
engine-aware performance analysis. However, as it stands, the provided
material is effectively contentless and does not offer a basis for a
technical evaluation.

Best regards,

Sepehr

Hi Sepehr,

I've also been following the discussions on the mailing list.

My read is that Yuya has been the one most welcoming to you. He was
putting in a word for you during the discussion about message phrasing,
providing you some guidance and expressing willingness to involve you in
the i18n work. His openness is visible even now -- unlike most of us, he
is trying out your code and giving you feedback.

Therefore it is a bit sad to see you being angry and dismissive at him
in the latest discussions. I think you are mistaking his short
statements for hostility or gatekeeping. My suggestion: stop throwing
away his goodwill. If an experienced contributor is giving you feedback,
you should seriously consider that there might be something true and
useful.

Regarding the latest discussion I would like to add that admitting lack
of expertise in zend engine (or anything else) is usually not seen here
as a sign of weakness, but of honesty. Many of the readers and voters
here are not experts on every detail either. If someone admits not
entirely understanding what's going on, it gives you a chance to provide
explanations and proof instead of dismissing his benchmarks as useless.

By the way...

Just for your information: someone praised my work who holds a high
position in php-src and whom I truly respect--meaning your opinion
doesn't really matter to me.

Different open source communities may work differently, but in this one
a reference to an unnamed figure is unlikely to earn you additional
respect or authority. It's best to leave such statements out.

BR,
Juris

PHP 8.4.26RC1 available for testing

Thu, 10 Sep 2026 15:16:09 +0000

Hi all!

PHP 8.4.26RC1 has just been released and may be downloaded from
https://downloads.php.net/~saki/

Or use the git tag: php-8.4.26RC1

Windows binaries are available at: https://www.php.net/pre-release-builds.php#windows

Please test it carefully, and report any bugs at https://github.com/php/php-src/issues

8.4.26 should be expected in 2 weeks, i.e. on Sep 24th.

Hash values and PGP signatures can be found below or at
https://gist.github.com/SakiTakamachi/7c50ca07945fdcad9a90d09fb7f7eaf8

Thank you, and happy testing!

Regards,
Saki Takamachi, Calvin Buckley, and Eric Mann

php-8.4.26RC1.tar.bz2
SHA256 hash: afaf140fa8f2593b3e08e3cff2ec81f62d1d8b21834439309e456c90a9ca1312
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEBhbpPZWvRxJD4mdhdwQm4X67s90FAmqgJE0ACgkQdwQm4X67
s91KWw//Qdumom2nZY8KqSvpJ+bRPcveuQdjVIogWWkM7Rg9sMFaRvJE38lWZx32
6akexo7nml/YVZ+WPvxWe40uB1mKkTPZtGQzUjalIDON+Au0ABlxr4NKklr5xTcP
RrwgJjnawd/fvW+DvxYDuv1AilNBkEpd4NBKmBed42UdhrosC/Y09DWvZITDAcGp
LQZPovfjQQ2eo9GHgHb9Os63zoHjAs5ROW/ExZ6Y2b6HLMxbAkHwexFc+u8uQD96
nIxUbYSoPidn6PG8Ky7O6jOdjAkzqXmE5Y+0+qJhcW4Cq6+J9s2dI4ObbxUCJLFf
cHuyvWws4/Twpky0rTkmdDWHEqMVWek+3a/6BygXEjMlYw4r7TsU2eHlYTSRMbpB
atr11kyCMhDl9WZxFQb/nafgeNLQTBP8FmMnI/HR4rGIt99SDJUtjuCOMkWH+BAf
SlWOLKo74RUznGICe9+K5hmdyrI/xRLxOrqxcliB1sEeskOzaj43oSpB7vzN+hSH
hWlYI/vW13PwdVWJ09EZYvoh7OvK17t9fa775NG80pfXXg7pco2PNic4fmdfofHv
VNK258mltIpBrIVVwnVrjO4azWWQ4oUZG5dlKA5+UqQA42v4eowsf+DgLnp/rBgQ
28Ylj5AxqP4epGSdRpfnFJjCbwvSpOYz7kYAGeU73iWayLh9deI=
=kouZ
-----END PGP SIGNATURE-----

php-8.4.26RC1.tar.gz
SHA256 hash: 48a559ba2cb17f21a4bbbf21624e616e5c7e3d4ce92eba7ffbc260c3b52bba5f
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEBhbpPZWvRxJD4mdhdwQm4X67s90FAmqgJE4ACgkQdwQm4X67
s92wWBAAkOs6DB26g44IXPVaTTYNt6ch6CCU+uS1e79vKSXBjYN++T/01WN9N3mr
dxzObadXPFtBEeMzGVX27JLUNbN+CkNlaRNXXeX78FpuEr4McWCvgLW+MJtEIZY3
BKkaV/yqf7Wf+GM8KzwaJmaz7VBIyqOo2uDAabpL1PSRTIbQlk8lNudv784zqLsI
otZVHJ2/oP4Is0Qgq0XpZUgISsi69L7U4fsC6wRoZKbTq25FYYYHyKObOAK8HlmZ
HVGfH0v+CnwZcxUA+UM3sl5CdZabVGpcD2assPRBRMSN/iIAJn2Vq6YZkMckvERg
63xruoOKmuNBn+fWrfJHlj38KbT1f3mtKQ7ZoNv+pK9/+RrOnZC2Y+iDZPijJMYk
GpRZQNrkZhE21ChWgfM63qwtkA/0ju1DsrwLvRqzjnGBPGsEBSJBUvkFOR+Rva0F
nY+aMFnDh6wiRctjqLsuxDZdSg9JHArX/VYcVF2OFm2GiPJfId8/cFqtQfba3Mfp
f7pzfVZxb+18kaNLFhOq7n//Tv4K1XhXk9Pe6Fgtsblkj+iNguPsSCjIAH5rsVTg
zuW0Bsy37L8dlYgSBK4kYqX0VvDWA2p5kdUlcxjZFvZFtn7kxtcisC/A912Oq3Ba
YcrTGlQZB3nGt0cTdXwwPlw/xR01uqhCJdcEtGic9oHMCICx0yE=
=EdEg
-----END PGP SIGNATURE-----

php-8.4.26RC1.tar.xz
SHA256 hash: c6e6f52752510c3b3fbaf9e34a9ec37fb17f6741fb8b2637d6804a8a71c4fc37
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEBhbpPZWvRxJD4mdhdwQm4X67s90FAmqgJE4ACgkQdwQm4X67
s92LxRAAnZl/soguNn8wB5fUzCvEkT4qFkKIa6oY+h3Ngagw6Xqp51mLZEE5FhOq
nf5zOIMuiWEDKJzQ8AMsGrnqgs97dTeQCTLWIHkG/3AEvVKakFKksMwtMNFxwb7F
TxQ6Io/yJMYDuVubyUf6qDbd9UgxJAVOkEzEBkVQJQnDJZbkMKfV9ov13LrUJjtD
dP2b2CWOpbBWeGUttNFhySIw2OUM8UFkwCrGGusDUcqbrE0BSD42MICHVAvpOmON
R9OSPpoBc4uaVdM5OgfAZ36pp+HaPaLDKluFQI+iqLOlsFlUNAZF0c50kdFLudpn
eFm07rjn4Xwb09wBBL2MZ8rMC7pfH4Q/tUIb+udeGKe3xiInabZ48YCJBomkVUgp
iEr9Fr8qzQnFSP3mW4og/pa4F/w4M8YJ9odkBb8xMwNUxi8wbbS9JeWkuVMvtfTG
c+e7aKLX6ZJ5PeEgA9Igmcvx96thvyORkp2Qpzy30QQC6pLxE8AoJNC073o6vvbJ
bN+JP/FvqnUEI51+itrMyHJdctHvy+0SV6xvr+POMs/DS/xkiKWqmqkwaUyFzm48
dSlNJfgl588Fvr3LmWHfn7zHX2n2ZuYcZEa/W4VJqWlvdIfW4gWknv/skp1J5ulK
5zivia5ug0S0n1KUYWqvE7EsVnbNT+NpkRbFO/1Hr1agk716hCE=
=X/15
-----END PGP SIGNATURE

SNMP RFC amendments and clarification

Thu, 10 Sep 2026 13:20:08 +0000

Hi

The following RFC https://wiki.php.net/rfc/snmp_improvements_2026
stipulated that the proposed PHP versions for this RFC are: "Next
stable release for all currently supported PHP versions."

This goes against our policy regarding versioning
(https://github.com/php/policies/blob/main/release-process.rst#patch-version-number).

As such these changes will only land in PHP 8.6.

Moreover, I suggested replacing the new integer constants for the
"Implement more MIB parsing and value output controls" part of the
RFC by PHP enums to improve type safety from the userland perspective.
I think this is an improvement on multiple levels as it also
effectively "translates" the C enums defined by SNMP to PHP enums
exposed to userland.

The plan is to have this merged in time for PHP 8.6.0beta2 so people
can test this.

Thank you. Both amendments make sense do me.

Can you (or Steven) shortly mention the changes in an Errata section
in the RFC so that it's clear to everyone reading the RFC that the
final version differs from what was being voted on? See
https://wiki.php.net/rfc/partial_function_application_v2#errata or
https://wiki.php.net/rfc/redact_parameters_in_back_traces#errata as an
example.

The “Status: Accepted” at the top RFC could be updated to
“Implemented” at the same time.

Best regards
Tim Düsterhus

Hi,

I've updated the wiki with both the new status and the errata section.

regards

Steve

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 12:39:36 +0000

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۱۵:۳۷ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 20:40 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I’ve been following the discussions and recent feedback regarding the
array_str_contains() RFC closely. Performance and speed comparisons have
come up as a key point, especially around whether a dedicated internal C
implementation provides sufficient value compared to a userland foreach
loop.

I'd love to open up a constructive and transparent discussion around
the benchmarking methodology we're using here. Some of the initial numbers
shared recently don't seem to reflect real-world scenarios or different
data profiles (like varying array sizes, early exits vs worst-case lookups,
UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be
great if we could align on:

The exact benchmark scripts and test datasets we should use to
evaluate this fairly.

The compilation environment and flags used for generating these
metrics.

Where the potential overhead in the current C implementation is
coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for
everyday developers. I welcome any suggestions, insights, or benchmark
reproductions from the community so we can evaluate this RFC based on
solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff

.exp

.log

.out

.php

.phpt

.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi Internals,

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two critical
issues:

The provided implementation does not even build in my environment. It
is scientifically impossible to derive any performance conclusions from
code that fails to compile.

Given your own admission of limited familiarity with the Zend Engine
internals, the methodology applied here lacks the necessary technical rigor
for a valid assessment.

I am more than willing to engage with constructive, reproducible, and
engine-aware performance analysis. However, as it stands, the provided
material is effectively contentless and does not offer a basis for a
technical evaluation.

Best regards,

Sepehr

Hi

PLEASE UNZIP ATTACHED FILE. YOUR CODE.

Regards.
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Mr. Hamada,

If you lack a solid grasp of Zend Engine internals and core data structures
like zval—which is the very backbone of PHP’s C runtime—it feels like you
are simply relying on an AI assistant rather than technical understanding.
Without mastering zval and Zend memory handling, working at this level in C
is effectively crippled.

To answer your question: I am testing this on high-end industrial 64-bit
hardware, and your provided files still completely fail to build.

Perhaps you should tell your AI to think a bit harder before generating
patches and benchmarks.

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 12:04:43 +0000

‪2026年9月10日(木) 20:40 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai youkidearitai@gmail.com نوشت:

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I’ve been following the discussions and recent feedback regarding the array_str_contains() RFC closely. Performance and speed comparisons have come up as a key point, especially around whether a dedicated internal C implementation provides sufficient value compared to a userland foreach loop.

I'd love to open up a constructive and transparent discussion around the benchmarking methodology we're using here. Some of the initial numbers shared recently don't seem to reflect real-world scenarios or different data profiles (like varying array sizes, early exits vs worst-case lookups, UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be great if we could align on:

The exact benchmark scripts and test datasets we should use to evaluate this fairly.

The compilation environment and flags used for generating these metrics.

Where the potential overhead in the current C implementation is coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for everyday developers. I welcome any suggestions, insights, or benchmark reproductions from the community so we can evaluate this RFC based on solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff

.exp

.log

.out

.php

.phpt

.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi Internals,

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two critical issues:

The provided implementation does not even build in my environment. It is scientifically impossible to derive any performance conclusions from code that fails to compile.

Given your own admission of limited familiarity with the Zend Engine internals, the methodology applied here lacks the necessary technical rigor for a valid assessment.

I am more than willing to engage with constructive, reproducible, and engine-aware performance analysis. However, as it stands, the provided material is effectively contentless and does not offer a basis for a technical evaluation.

Best regards,

Sepehr

PLEASE UNZIP ATTACHED FILE. YOUR CODE.

Regards.
Yuya

--

Yuya Hamada (tekimen)

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 11:39:49 +0000

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai <
youkidearitai@gmail.com> نوشت:

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I’ve been following the discussions and recent feedback regarding the
array_str_contains() RFC closely. Performance and speed comparisons have
come up as a key point, especially around whether a dedicated internal C
implementation provides sufficient value compared to a userland foreach
loop.

I'd love to open up a constructive and transparent discussion around the
benchmarking methodology we're using here. Some of the initial numbers
shared recently don't seem to reflect real-world scenarios or different
data profiles (like varying array sizes, early exits vs worst-case lookups,
UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be
great if we could align on:

The exact benchmark scripts and test datasets we should use to
evaluate this fairly.

The compilation environment and flags used for generating these
metrics.

Where the potential overhead in the current C implementation is
coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for
everyday developers. I welcome any suggestions, insights, or benchmark
reproductions from the community so we can evaluate this RFC based on
solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff

.exp

.log

.out

.php

.phpt

.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi Internals,

Thank you all for the time and effort invested in this discussion.

Regarding the benchmarks provided by Yuya, I must address two critical
issues:

The provided implementation does not even build in my environment. It is
scientifically impossible to derive any performance conclusions from code
that fails to compile.
Given your own admission of limited familiarity with the Zend Engine
internals, the methodology applied here lacks the necessary technical rigor
for a valid assessment.

I am more than willing to engage with constructive, reproducible, and
engine-aware performance analysis. However, as it stands, the provided
material is effectively contentless and does not offer a basis for a
technical evaluation.

Best regards,

Sepehr

[Pre-RFC] Opt-in JSON comments and trailing commas

Thu, 10 Sep 2026 10:56:10 +0000

That is a language known as Microsoft's JSONC or Nigel Tao's JWCC (JSON
with Comments and Commas) they are effectively equivalent

I think this proposal makes sense and with regarding to Otar's questions
regarding naming, I think a single JSON_ALLOW_JSONC flag to allow both
comments and trailing commas would be the best option. If there's an
existing, reasonably widely accepted standard for that, we should just
reference it and not add separate flags that result in a combinatorial
explosion.

Best regards
Tim Düsterhus

SNMP RFC amendments and clarification

Thu, 10 Sep 2026 10:52:12 +0000

The following RFC https://wiki.php.net/rfc/snmp_improvements_2026
stipulated that the proposed PHP versions for this RFC are: "Next
stable release for all currently supported PHP versions."

This goes against our policy regarding versioning
(https://github.com/php/policies/blob/main/release-process.rst#patch-version-number).

As such these changes will only land in PHP 8.6.

Moreover, I suggested replacing the new integer constants for the
"Implement more MIB parsing and value output controls" part of the RFC
by PHP enums to improve type safety from the userland perspective.
I think this is an improvement on multiple levels as it also
effectively "translates" the C enums defined by SNMP to PHP enums
exposed to userland.

The plan is to have this merged in time for PHP 8.6.0beta2 so people
can test this.

Thank you. Both amendments make sense do me.

Can you (or Steven) shortly mention the changes in an Errata section in
the RFC so that it's clear to everyone reading the RFC that the final
version differs from what was being voted on? See
https://wiki.php.net/rfc/partial_function_application_v2#errata or
https://wiki.php.net/rfc/redact_parameters_in_back_traces#errata as an
example.

The “Status: Accepted” at the top RFC could be updated to “Implemented”
at the same time.

Best regards
Tim Düsterhus

[RFC] [VOTE] PREG_THROW_ON_ERROR

Thu, 10 Sep 2026 10:41:26 +0000

First...wrapping couples the exception you catch to the flag.
Without it, preg_replace_callback() throws whatever the callback
throws.
With it, the same call always throws a PregException.
So the flag silently changes which exception a caller has to handle,
and the two have to move together:
try {
    preg_replace_callback(
        '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
        function ($matches) {
            return mask_credit_card($matches[0]); // throws 
MaskException
        },
        $contents,
    );
} catch (MaskException $e) {
    // becomes dead the moment the flag is added, and comes back the
moment it's removed
}

That is correct, but as I mentioned before, the new flag is an entirely
new feature that requires an explicit opt-in. Adopting a new feature
without reading the associated documentation to find out how it works
will generally result in sadness, and I believe this case is no
different. Also adding and removing the flag would not just affect
MaskException, but would of course also affect whether or not a
PregException is thrown and whether or not the code proceeds after an
error was encountered. Any existing error handling would need to adapted
as well. So the changes required to adopt the flag are much more
far-reaching than whether or not a catch block for a custom exception
would need to be adjusted.

Second...wrapping a callback's exception in a PregException produces
a PregException that maps to no preg error.

I think that is fine: Just add a new PREG_CALLBACK_ERROR that is only
emitted when PREG_THROW_ON_ERROR is set.

You can be holding a PregException while preg_last_error() and
preg_last_error_msg() report no error at all. That is an exception
whose type says a regex error happened when, by preg's own state, none
did.

Ah, good that you mention this, because it's not mentioned in the RFC
and I didn't check the implementation: The preg_last_error() value
should not be touched when the PREG_THROW_ON_ERROR flag is set. Once
you opt into exception-based error handling, the other error handling
path should be bypassed entirely. This is consistent with how
JSON_THROW_ON_ERROR already works: https://3v4l.org/Ijt3R#veol

 &lt;?php

 echo "Start\n";
 var_dump(json_last_error());
 echo "\n";

 echo "Error without flag\n";
 json_decode('{');
 var_dump(json_last_error());
 echo "\n";

 echo "Clear error\n";
 json_decode('true'); // clear error
 var_dump(json_last_error());
 echo "\n";

 echo "Error with flag\n";
 try { json_decode('{', flags: JSON_THROW_ON_ERROR); } catch

(\JsonException $e) { echo $e->getMessage(), "\n"; }
var_dump(json_last_error());
echo "\n";

 echo "Set different error\n";
 json_decode(str_repeat('[', 1000));
 var_dump(json_last_error());

 echo "and check that it is not overwritten when `JSON_THROW_ON_ERROR`

is set\n";
try { json_decode('{', flags: JSON_THROW_ON_ERROR); } catch
(\JsonException $e) { echo $e->getMessage(), "\n"; }
var_dump(json_last_error());

This is separate from the $e->getMessage() === preg_last_error_msg()``
guarantee I raised before. Even setting that aside, it's incoherent on
its own terms, because the flag is PREG_THROW_ON_ERROR and
preg_last_error() is what an error is.

So keeping that honest means a bare PregException can no longer
stand for two different things at once.

So with the above note that preg_last_error() should remain untouched,
I believe having a single PregException for everything is fine (or
PregError + PregException, as pointed out by Robert).

Best regards
Tim Düsterhus

[Meta] This Week In PHP Internals | September 9, 2026

Thu, 10 Sep 2026 06:43:20 +0000

Hi Contributors,

This week's episode is out. Here's the video, plus everywhere else it landed
for visibility.

Two editorial notes. Last week's corrections are at the top of this episode:
8.4.25 was a bug-fix release, not a security one (thanks, Daniel), and the two
libxml-rs contributors I described without naming were James Gilliland and
David Carlier (thanks, Tim — the From header was right there).

Same invitation as always: if I got something wrong, reply in this thread and
I'll make corrections. That includes how I'm pronouncing your names.

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: https://dev.to/projektgopher/this-week-in-php-internals-sept-9-2026-1dao

youtube https://youtu.be/AoMmbSOknmw
r/php https://www.reddit.com/r/PHP/comments/1wc9mwz/this_week_in_php_internals_sept_9_2026/
r/symfony https://www.reddit.com/r/symfony/comments/1wc9usw/this_week_in_php_internals_sept_9_2026/
r/laravel https://www.reddit.com/r/laravel/comments/1wca342/this_week_in_php_internals_sept_9_2026/
dev.to https://dev.to/projektgopher/this-week-in-php-internals-sept-9-2026-1dao
mastodon https://phpc.social/@ProjektGopher/117245178070805498
threads https://www.threads.com/@projektgopher/post/DdGI_TEFJte
bsky https://bsky.app/profile/projektgopher.com/post/3mv5ex3nphd2z
twitter https://x.com/ProjektGopher/status/2097933365915906537
linkedin https://www.linkedin.com/feed/update/urn:li:activity:7503701996701569024/
pinkary https://pinkary.com/@ProjektGopher/questions/01a089ed-e4e3-7105-8d20-a61e0d6a9bff

Cheers,
Len

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 02:33:41 +0000

‪2026年9月10日(木) 10:07 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi everyone,

I hope you're all having a great week.

I’ve been following the discussions and recent feedback regarding the array_str_contains() RFC closely. Performance and speed comparisons have come up as a key point, especially around whether a dedicated internal C implementation provides sufficient value compared to a userland foreach loop.

I'd love to open up a constructive and transparent discussion around the benchmarking methodology we're using here. Some of the initial numbers shared recently don't seem to reflect real-world scenarios or different data profiles (like varying array sizes, early exits vs worst-case lookups, UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be great if we could align on:

The exact benchmark scripts and test datasets we should use to evaluate this fairly.

The compilation environment and flags used for generating these metrics.

Where the potential overhead in the current C implementation is coming from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for everyday developers. I welcome any suggestions, insights, or benchmark reproductions from the community so we can evaluate this RFC based on solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Hi Internals

For your reference, I have attached the benchmark diff files. (commit
hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)

.diff
.exp
.log
.out
.php
.phpt
.sh

I can not find definite improve performance.
(My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)

I don't familiar with Zend Engine's performance, However I think
function's performance improvement is limited.

Regards
Yuya

--

Yuya Hamada (tekimen)

Discussion on array_str_contains() RFC and performance benchmarking methodology

Thu, 10 Sep 2026 01:03:10 +0000

Hi everyone,

I hope you're all having a great week.

I’ve been following the discussions and recent feedback regarding the
array_str_contains() RFC closely. Performance and speed comparisons have
come up as a key point, especially around whether a dedicated internal C
implementation provides sufficient value compared to a userland foreach
loop.

I'd love to open up a constructive and transparent discussion around the
benchmarking methodology we're using here. Some of the initial numbers
shared recently don't seem to reflect real-world scenarios or different
data profiles (like varying array sizes, early exits vs worst-case lookups,
UTF-8 strings, and compiler optimization flags like -O2 / -O3).

Before drawing final conclusions on performance, I think it would be great
if we could align on:

The exact benchmark scripts and test datasets we should use to evaluate
this fairly.
The compilation environment and flags used for generating these metrics.
Where the potential overhead in the current C implementation is coming
from and how we can optimize it together.

My goal has always been to make PHP more expressive and efficient for
everyday developers. I welcome any suggestions, insights, or benchmark
reproductions from the community so we can evaluate this RFC based on
solid, agreed-upon data.

Thanks for your time and feedback!

Best regards,
Sepehr

Wed, 09 Sep 2026 20:35:45 +0000

Hi Yuya, the "genius",

Look—I don't just talk.

First, when I introduced the RFC, before the discussion started, many
people asked: "How is this different from other functions like
array_search?" I provided the analysis, and there were many questions like
that.

You told me to run a real-world test, and you saw that my function
performed better than those functions.

All the code was designed based on proper principles, and I am sure you saw
that yourself. You didn't even leave a single comment during the discussion
period because you knew you would face a completely technical response.

Just for your information: someone praised my work who holds a high
position in php-src and whom I truly respect—meaning your opinion doesn't
really matter to me.

Respectfully,
Sepehr

در تاریخ چهارشنبه ۹ سپتامبر ۲۰۲۶، ۱۹:۴۷ youkidearitai <
youkidearitai@gmail.com> نوشت:

No, If you are a skilled engineer, you should accept criticism.
Your skill is not enough php-src development.

To begin with, To unable resolving issue, You must compile and test on
your PC.
Otherwise, Your problem is CI is red, but your test code is broken.
Not CI's problem.
Fix below..

========DIFF========
001- === BENCHMARK RESULTS (%d iterations) ===
002- [Match at start]
003- C (array_str_contains) : %f ms
004- Userland (foreach) : %f ms
005- Speedup : %f x faster
001+ === BENCHMARK RESULTS (1,000 iterations)label

007- [Match in middle]
008- C (array_str_contains) : %f ms
009- Userland (foreach) : %f ms
010- Speedup : %f x faster
003+ [Match at start]
004+ C (array_str_contains) : 11.40 ms
005+ Userland (foreach) : 2.74 ms
006+ Speedup : 0.24x faster

012- [Match at end]
013- C (array_str_contains) : %f ms
014- Userland (foreach) : %f ms
015- Speedup : %f x faster
008+ [Match in middle]
009+ C (array_str_contains) : 12.85 ms
010+ Userland (foreach) : 5.94 ms
011+ Speedup : 0.46x faster

017- [No match (all)]
018- C (array_str_contains) : %f ms
019- Userland (foreach) : %f ms
020- Speedup : %f x faster
013+ [Match at end]
014+ C (array_str_contains) : 11.58 ms
015+ Userland (foreach) : 7.16 ms
016+ Speedup : 0.62x faster
017+
018+ [No match (all)]
019+ C (array_str_contains) : 6.47 ms
020+ Userland (foreach) : 8.22 ms
021+ Speedup : 1.27x faster
========DONE========
FAIL Benchmark array_str_contains vs userland implementations
[ext/standard/tests/array_str_contains_benchmark.phpt]

Furthermore, seems don't increase speed. This approach is maybe wrong.

Anyway, You seems don't hear from people.
Please hear from people.

Yuya

‪2026年9月9日(水) 20:56 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬
در تاریخ چهارشنبه ۹ سپتامبر ۲۰۲۶، ۱۳:۵۹ youkidearitai <
youkidearitai@gmail.com> نوشت:
No,

‪2026年9月9日(水) 0:40 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬
Hi Yua,

Thanks for your follow-up and for the time you've dedicated to this.

As you know, we've been encountering Segmentation Fault or
Timeout errors in the CI tests. I've reduced the benchmark iterations
from 100,000 to 1,000 to see if the issue was due to excessive system load,
but unfortunately, the CI error persists, and it seems the problem lies
elsewhere.

The exact cause of this error is still unclear at this moment.

Following this function, I plan to work on graphics-related functions
such as mask, str_mask, and others.

در تاریخ سه‌شنبه ۸ سپتامبر ۲۰۲۶، ۰۸:۰۹ youkidearitai <
youkidearitai@gmail.com> نوشت:
Hi Sepehr

That PR fails your test.
Please compile and test from your PC before push the CI.
You can check php-src's README
https://github.com/php/php-src/blob/master/README.md, If you don't
understand how to build and test.
  ========DIFF========
  001- === BENCHMARK RESULTS (%d iterations) ===
  002- \[Match at start\]
  003-   C (array_str_contains) : %f ms
  004-   Userland (foreach)     : %f ms
  005-   Speedup                : %f x faster
  001+ === BENCHMARK RESULTS (100,000 iterations) ===

  007- \[Match in middle\]
  008-   C (array_str_contains) : %f ms
  009-   Userland (foreach)     : %f ms
  010-   Speedup                : %f x faster
  003+ [Match at start]
  004+   C (array_str_contains) :  577.66 ms
  005+   Userland (foreach)     :   13.74 ms
  006+   Speedup                :    0.02x faster

  012- \[Match at end\]
  013-   C (array_str_contains) : %f ms
  014-   Userland (foreach)     : %f ms
  015-   Speedup                : %f x faster
  008+ [Match in middle]
  009+   C (array_str_contains) :  632.95 ms
  010+   Userland (foreach)     :  251.77 ms
  011+   Speedup                :    0.40x faster

  017- \[No match (all)\]
  018-   C (array_str_contains) : %f ms
  019-   Userland (foreach)     : %f ms
  020-   Speedup                : %f x faster
  013+ [Match at end]
  014+   C (array_str_contains) :  625.46 ms
  015+   Userland (foreach)     :  482.63 ms
  016+   Speedup                :    0.77x faster
  017+
  018+ [No match (all)]
  019+   C (array_str_contains) :  465.12 ms
  020+   Userland (foreach)     :  474.41 ms
  021+   Speedup                :    1.02x faster
Regards
Yuya

‪2026年9月8日(火) 2:21 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi Yuya,

Could you please take a look at the failed CI checks in my PR when
you have time?

https://github.com/php/php-src/pull/23512/checks

I’m getting 503 Service Unavailable errors when trying to access
the logs, so I haven’t been able to determine whether the failures
are related to my changes.

I’m particularly concerned about the Tracing JIT and FreeBSD
failures.
I’d appreciate your help understanding them, or rerunning the
failed
jobs if appropriate.

Thank you for your time.

Best regards,
Sepehr

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai
As I mentioned on GitHub,
https://github.com/php/php-src/pull/23512#issuecomment-5594220142
CI red is your test code is wrong, It's not CI timeout.
You can confirm when build & test on your local PC.

I'm telling you straight, If you cannot hear from PHP internals
people, You are not enough ability on php-src yet.
You can choose other way to contribute in PHP.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai
Hello Yuya,
Mr. Hamada—several prominent figures in the PHP community have praised
my work.
Please bear in mind that I am just preparing my very first function—and
yes, it had a minor issue that I shared with you.
There was a time when you, too, were creating your first function and
surely encountered a small glitch—unless, of course, you happen to be Larry
Page. So, instead of being so critical, please offer your support and
encouragement to someone who—arguably—is among the first one or two
Iranians to reach this level through exceptional programming skills.
Best regards,
Sepehr
--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

[RFC] [VOTE] PREG_THROW_ON_ERROR

Wed, 09 Sep 2026 12:35:52 +0000

It also violates the exception policy in
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables,
which states:

If an extension uses external functionality that may throw an exception it MUST wrap any exception thrown by that functionality into an appropriate exception of its own. It MUST set the $previous property to the original exception when doing so.

I've read this last week and this interpretation of the exception
policy has taunted me since then. Tim, I think you are mistaken in your
point of view on this. I'm not aware of any point where exceptions
thrown in user callback methods are wrapped, but at least autoloading,
a very prominent one, does not. https://3v4l.org/vYmts Changing this
(in general for all user callbacks) would be a very inconvenient BC
break for many projects.

Yes, much of the existing standard library predates the policy and more
generally also predates any kind of API design regarding exceptions.
The first part of the standard library where the Exception hierarchy got
any real design is the new random API in PHP 8.2 - and that served as
the blueprint for the new URI extension and the exception policy.

Regarding your specific example of autoloading, I'd argue that the
correct behavior for autoloading is to wrap all exceptions. From a user
perspective, autoloading is a blackbox service and it thus should behave
like any other service (e.g. like the session example I have given in a
previous email in this thread). In particular autoloading shows up
“implicitly” in many cases and having a clear indicator that autoloading
is what failed is useful. As an example, when using class_exists(), I
don't want arbitrary exceptions to show up: https://3v4l.org/m0DIP#veol

I think this policy should be read differently. I think as a language
user you should not have to be aware of the implementation of a
functions internals. if some function is using something that could
throw an exception this implementation detail should be hidden from the
user. Also because if the function is re-implemented another way this
exception could change. From the perspective of the language user, a
callable provided to a function is not part of the functions internals.

I would agree for functions like array_map() or array_filter() where
the sole purpose is executing the user callback and which cannot fail
for other reasons. But for preg_replace_callback() and similar, the
high level operation is “perform a replacement” and the provided
callback is just an implementation detail. I would find it unexpected
that preg_replace() with a broken replacement string (e.g.
hypothetically referencing a group that doesn't exist, this case
currently doesn't seem to emit an error) would throw PregException,
but preg_replace_callback() with a broken replacement callback would
throw arbitrary errors.

Best regards
Tim Düsterhusp

Wed, 09 Sep 2026 11:56:25 +0000

در تاریخ چهارشنبه ۹ سپتامبر ۲۰۲۶، ۱۳:۵۹ youkidearitai <
youkidearitai@gmail.com> نوشت:

No,

‪2026年9月9日(水) 0:40 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬
Hi Yua,

Thanks for your follow-up and for the time you've dedicated to this.

As you know, we've been encountering Segmentation Fault or Timeout
errors in the CI tests. I've reduced the benchmark iterations from 100,000
to 1,000 to see if the issue was due to excessive system load, but
unfortunately, the CI error persists, and it seems the problem lies
elsewhere.

The exact cause of this error is still unclear at this moment.

Following this function, I plan to work on graphics-related functions
such as mask, str_mask, and others.

در تاریخ سه‌شنبه ۸ سپتامبر ۲۰۲۶، ۰۸:۰۹ youkidearitai <
youkidearitai@gmail.com> نوشت:
Hi Sepehr

That PR fails your test.
Please compile and test from your PC before push the CI.
You can check php-src's README
https://github.com/php/php-src/blob/master/README.md, If you don't
understand how to build and test.
  ========DIFF========
  001- === BENCHMARK RESULTS (%d iterations) ===
  002- \[Match at start\]
  003-   C (array_str_contains) : %f ms
  004-   Userland (foreach)     : %f ms
  005-   Speedup                : %f x faster
  001+ === BENCHMARK RESULTS (100,000 iterations) ===

  007- \[Match in middle\]
  008-   C (array_str_contains) : %f ms
  009-   Userland (foreach)     : %f ms
  010-   Speedup                : %f x faster
  003+ [Match at start]
  004+   C (array_str_contains) :  577.66 ms
  005+   Userland (foreach)     :   13.74 ms
  006+   Speedup                :    0.02x faster

  012- \[Match at end\]
  013-   C (array_str_contains) : %f ms
  014-   Userland (foreach)     : %f ms
  015-   Speedup                : %f x faster
  008+ [Match in middle]
  009+   C (array_str_contains) :  632.95 ms
  010+   Userland (foreach)     :  251.77 ms
  011+   Speedup                :    0.40x faster

  017- \[No match (all)\]
  018-   C (array_str_contains) : %f ms
  019-   Userland (foreach)     : %f ms
  020-   Speedup                : %f x faster
  013+ [Match at end]
  014+   C (array_str_contains) :  625.46 ms
  015+   Userland (foreach)     :  482.63 ms
  016+   Speedup                :    0.77x faster
  017+
  018+ [No match (all)]
  019+   C (array_str_contains) :  465.12 ms
  020+   Userland (foreach)     :  474.41 ms
  021+   Speedup                :    1.02x faster
Regards
Yuya

‪2026年9月8日(火) 2:21 ‫سپهر محمودی‬‎ sepehrphpr@gmail.com:‬

Hi Yuya,

Could you please take a look at the failed CI checks in my PR when
you have time?

https://github.com/php/php-src/pull/23512/checks

I’m getting 503 Service Unavailable errors when trying to access
the logs, so I haven’t been able to determine whether the failures
are related to my changes.

I’m particularly concerned about the Tracing JIT and FreeBSD failures.
I’d appreciate your help understanding them, or rerunning the failed
jobs if appropriate.

Thank you for your time.

Best regards,
Sepehr

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai
As I mentioned on GitHub,
https://github.com/php/php-src/pull/23512#issuecomment-5594220142
CI red is your test code is wrong, It's not CI timeout.
You can confirm when build & test on your local PC.

I'm telling you straight, If you cannot hear from PHP internals
people, You are not enough ability on php-src yet.
You can choose other way to contribute in PHP.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hello Yuya,
Mr. Hamada—several prominent figures in the PHP community have praised my work.
Please bear in mind that I am just preparing my very first
function—and yes, it had a minor issue that I shared with you.
There was a time when you, too, were creating your first function and
surely encountered a small glitch—unless, of course, you happen to be
Larry Page. So, instead of being so critical, please offer your
support and encouragement to someone who—arguably—is among the first
one or two Iranians to reach this level through exceptional
programming skills.
Best regards,
Sepehr

[RFC] [VOTE] PREG_THROW_ON_ERROR

Wed, 09 Sep 2026 11:34:01 +0000

Hi

Arguably this specific case is a bit debatable, but as the author of
the
throwable policy RFC, I believe that it is at least violated in
spirit.
The goal of the throwable policy generally, and also with regard to
that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block.

Obviously you wrote the policy and so are best placed to interpret it
(and I am not a core developer / person with voting rights); however I
agree with the angle Osama is coming from here - I wouldn't say this
is an error that is (always) part of the same group. There wasn't any
error in the call to preg_replace_callback itself (or any of its
functionality) - the error was in a way during the processing of the

Yes, I agree that this case is not entirely clear-cut - and it's good
we're having this discussion now.

If I have understood the other example correctly, this contradicts
quite significantly with the CSPRNG throwing an Exception that
RandomException contains - as the failure is a core issue within the
function call itself as opposed to logic that occurs in userland.

I think there might be a misunderstanding based on how you phrased that
paragraph. To provide a more specific example:

Consider I have a session implementation that uses Redis as its session
storage backend. Session IDs need to be created using secure randomness,
i.e. using the CSPRNG. Both the Redis backend and the CSPRNG can
theoretically fail. As a user when create a new session I want to be
able to just catch (SessionInitializedFailedException) and not care
about whether the CSPRNG or the Redis connection failed, and I might not
even know if it's Redis, Memcache, a File System or a MySQL database.
Thus any underlying issues must be wrapped into a session-specific
exception.

preg_replace_callback() is different in that I explicitly pass in a
callback and thus I'm technically in full control over the code that is
being executed and I can theoretically know what exceptions could
possibly be thrown and might intentionally want to handle them
explicitly. On the other hand, failing to execute the callback means
that the replacing operation failed, no further callbacks will be called
and preg_replace_callback() will not return anything - and that is a
“running this regex failed” a.k.a. PregException situation to me.

If anything, I would argue that under the policy this should go the
other way and become PregError:

The Error hierarchy MUST NOT be used for errors that are expected to
be thrown (and caught) during normal operation of a PHP program.
In terms of the possible errors that could occur, I would expect at
least PREG_INTERNAL_ERROR, PREG_BAD_UTF8_ERROR &
PREG_JIT_STACKLIMIT_ERROR to be code errors that require a developer
to need to correct their code (as my understanding of these would be
that the pattern is invalid, or not quoted correctly, etc. Although
PREG_BACKTRACK_LIMIT_ERROR & PREG_RECURSION_LIMIT_ERROR are more
likely to occur based on user input, then the limit for both is
controlled by an ini setting - so again, this likely isn't something I
would say is expected to be thrown and caught during normal operation
of a PHP program. The final error (PREG_BAD_UTF8_OFFSET_ERROR) I
think would still likely need a code change to fix it occurring -
although I have only done a quick Google to see when it may occur.

This is a good point. I agree that things like pattern compilation
failures should be a PregError, since this is a clear programmer error
and regular expressions are not supposed to be untrusted inputs. For the
error error situations I would need to check as well if they are
expected during regular operation or not. The backtrack or recursion
limits I can see being caught intentionally to provide better error
messages to a user (thus PregException).

Best regards
Tim Düsterhus

Hi Tim,

A couple of updates after digging into this further...

I found a case that makes the $e->getMessage() === preg_last_error_msg()`` guarantee I leaned on not really hold in general.
A PregException freezes its message and code when it is thrown, but
preg_last_error_msg() reads the per-request global.
And so the two agree only while nothing runs between the throw and the read.
A callback that makes its own flagged call breaks that...when the inner
call throws, the outer operation bails and overwrites the global with
INTERNAL_ERROR (why it lands on that code is point 2) before you read it.

For example:

try {
    preg_replace_callback(
        '/\w/',
        function ($m) {
            preg_match('//u', "\xff", $inner, PREG_THROW_ON_ERROR);   //
the inner call throws
            return 'Y';
        },
        'a',
        flags: PREG_THROW_ON_ERROR,
    );
} catch (\PregException $e) {
    var_dump($e->getMessage());        // "Malformed UTF-8 characters, ..."
 frozen in the exception
    var_dump(preg_last_error_msg());   // "Internal error" the global,
already overwritten
    var_dump($e->getCode());           // 4   PREG_BAD_UTF8_ERROR
    var_dump(preg_last_error());       // 1   `PREG_INTERNAL_ERROR` 
}

So the equality is a property of a single flagged call, not an
invariant...and the exception is a faithful snapshot of its own call, while
preg_last_error_msg() is a global the next call moves.

I should have stated it that narrowly.

I was also wrong about the callback case.
When a user callback throws, PHP does set preg_last_error() and
preg_last_error_msg().
They come back as PREG_INTERNAL_ERROR and "Internal error", not "No
error", so my earlier claim that a callback throw leaves the error state
untouched was incorrect.

I dug in the C code to see how that works, and how that value gets set
changes what it means.
When the callback throws, the replacement bails out (
https://github.com/php/php-src/blob/82a15338e298142f52854b64d803695d4e5252df/ext/pcre/php_pcre.c#L1960),
and the error: path calls pcre_handle_exec_error(count) (
https://github.com/php/php-src/blob/82a15338e298142f52854b64d803695d4e5252df/ext/pcre/php_pcre.c#L2032-L2033
).
At that point count is the successful match count, not a PCRE error code,
and pcre_handle_exec_error() has no case for a non-negative value, so it
falls through to its default and returns PHP_PCRE_INTERNAL_ERROR (
https://github.com/php/php-src/blob/82a15338e298142f52854b64d803695d4e5252df/ext/pcre/php_pcre.c#L132
).
The engine matched fine, but the "Internal error" is a fallback the
bail-out path leaves behind, not a diagnosis of anything PCRE did wrong.

That means there is no real message for this case...
A genuine PCRE error carries a specific reason ("Malformed UTF-8 ...",
"Backtrack limit exhausted", and so on...)...
A callback throw only ever yields the generic "Internal error", because
nothing in PCRE actually failed.
The real information is the exception the callback threw, which carries its
own message and type.

So I would say this case is unlike the PCRE errors in a concrete way...that
is for them the error state describes the failure, but here it does not.

To me that leans (though it does not settle) toward letting the callback's
exception propagate rather than wrapping it.
Wrapping would turn a specific userland exception into a PregException
whose own message can only be "Internal error".
Whether that lean is enough, or whether not wrapping here is still a
violation of the throwable policy, I think is your call as its author. I am
only laying out what the code does.

With that said, I think the things we have so far that make the case for
letting the callback's exception propagate are:

A callback throwing is not a PCRE error. The engine matched, and
userland threw. The "Internal error" it records is the fallback above,
not a diagnosis.
There is no real message to deliver. The genuine message and type are
in the callback's own exception. A PregException here would carry only
"Internal error".
Wrapping destroys catch-by-type. Domain exceptions from the callback
all collapse into PregException, so callers can no longer catch them by
type and have to inspect ->getPrevious().
It is the more flexible default. A caller who wants a single catch can
throw a PregException from their own callback. A caller who wants their
own types back under wrapping cannot get them without catch-and-rethrow.

Now whether any of these is a knockout on its own is probably
arguable...But I think together they justify letting the callback's
exception propagate.

But of course it turns on how the throwable policy should apply, so I need
your judgement here.

Thanks,
Osama

[RFC] [VOTE] PREG_THROW_ON_ERROR

Wed, 09 Sep 2026 08:48:12 +0000

I disagree with the behavior of not wrapping Exceptions thrown in
user callbacks: I believe the correct choice is to throw a
\PregException with the Exception thrown in the callback as the
->previous exception. Not wrapping the user callback exception means
that one needs a catch(Exception) with a try just around the preg_
call to reliably handle all errors during regular expression execution,
which nullifies much of the benefit of having a dedicated exception
class in the first place.

It also violates the exception policy in
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables,
which states:

If an extension uses external functionality that may throw an exception it MUST wrap any exception thrown by that functionality into an appropriate exception of its own. It MUST set the $previous property to the original exception when doing so.

I've read this last week and this interpretation of the exception policy has taunted me since then. Tim, I think you are mistaken in your point of view on this. I'm not aware of any point where exceptions thrown in user callback methods are wrapped, but at least autoloading, a very prominent one, does not. https://3v4l.org/vYmts Changing this (in general for all user callbacks) would be a very inconvenient BC break for many projects.

I think this policy should be read differently. I think as a language user you should not have to be aware of the implementation of a functions internals. if some function is using something that could throw an exception this implementation detail should be hidden from the user. Also because if the function is re-implemented another way this exception could change. From the perspective of the language user, a callable provided to a function is not part of the functions internals.

Specifically for this case, wrapping the users' exceptions in this RFC to me is very contra-intuïtive because it is inconsistent with other callbacks. Do you have an example where this wrapping currently takes place?

Greetings, Casper

Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Tue, 08 Sep 2026 13:30:33 +0000

My perspective is that memory issues in PHP that cause crashes are
generally not good and should be resolved wherever possible. While PHP
9
may address many of these issues, it is still far off and production
code
migration will take even longer. Therefore, fixes now are still
relevant.

I agree with that. Also even if PHP 9 will remove all current
deprecations, there will certainly be new (engine) deprecations in the
PHP 9.x cycle and we're back to the status quo.

Best regards
Tim Düsterhus

Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Tue, 08 Sep 2026 13:28:15 +0000

As such I'd like to hear the opinions of Internals on if we can come to
a consensus (ideally without an RFC...) that registering callbacks that
mess around with state in non-intended ways is Undefined Behaviour (UB).

I'd still very much be in favor of fixing these issues, mainly because
they are a big time sink for the security team as well, due to
false-positive reports. Arnaud and I were planning on proposing an RFC
that mitigates at least a large portion of them, before we got occupied
with other things.

That is absolutely the ideal fix for this class of issues.

I absolutely do not think each case should be considered individually,
because we already tried this and the issues never stop coming.

True, but UB exists outside that class and those issues are worth the
attention imho.

--
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Tue, 08 Sep 2026 13:04:40 +0000

Hi Gina

Over the last few years, more and more issues have been opened where a user defined error handler (or other callbacks) causes a Use After Free (UAF) when said error handler modifiers the variable/property that triggered the warning/deprecation/whatever.
These issues are usually found via fuzzing, or more recently LLMs.
snip
One potential idea that has been floating around is to delay error handlers. [1]
However, these issue are likely to also happen from other callbacks such as a class autoloader, a tick handler, an output handler, etc. as nothing prevents them from messing around with $GLOBALS or binding a variable to its scope.

While having C memory bugs is far from ideal, the fact that a majority of them will disappear with PHP 9 when deprecation are removed and warnings are promoted to Error makes this whackamole bug chase a waste of time. Especially as these issues have been present for decades and nobody except fuzzers and LLMs have run into these issues.

I very much share this sentiment. Yes, ideally there are no ways to
trigger memory violations in PHP. However, while such bugs can be
catastrophic for other languages like JavaScript where it's expected to
run untrusted code on your computer, the same doesn't apply to PHP.
These bugs are effectively impossible to trigger by accident and thus
have no real-world consequence, and yet take up a very large chunk of
our time (both in terms of issues and reviews.

As such I'd like to hear the opinions of Internals on if we can come to a consensus (ideally without an RFC...) that registering callbacks that mess around with state in non-intended ways is Undefined Behaviour (UB).

I'd still very much be in favor of fixing these issues, mainly because
they are a big time sink for the security team as well, due to
false-positive reports. Arnaud and I were planning on proposing an RFC
that mitigates at least a large portion of them, before we got occupied
with other things.

I absolutely do not think each case should be considered individually,
because we already tried this and the issues never stop coming.

While UB is far from desirable, it is not unprecedented in PHP.
Prior to PHP 8, the behaviour of internal functions when given values of invalid types was considered UB, sometimes it returned false, sometimes, null, sometimes it threw an Error.
This was fixed by throwing TypeErrors consistently.

The above might not all be problematic. E.g. the number of handlers that
produce output are fairly limited. The reports we do get that use them
rely on warnings printed to the output buffer, but if we can delay
warnings then this goes away as well. Similarly, not that many handlers
trigger autoloading. So this might be easier to control. But I did not
verify my claims here. But if cases remain that aren't possible to fix,
I wouldn't mind officially disallowing them.

Ilija

Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Tue, 08 Sep 2026 12:17:28 +0000

While having C memory bugs is far from ideal, the fact that a majority
of them will disappear with PHP 9 when deprecation are removed and warnings
are promoted to Error makes this whackamole bug chase a waste of time.
Especially as these issues have been present for decades and nobody
except fuzzers and LLMs have run into these issues.

As such I'd like to hear the opinions of Internals on if we can come to a
consensus (ideally without an RFC...) that registering callbacks that mess
around with state in non-intended ways is Undefined Behaviour (UB).

While UB is far from desirable, it is not unprecedented in PHP.

My perspective is that memory issues in PHP that cause crashes are
generally not good and should be resolved wherever possible. While PHP 9
may address many of these issues, it is still far off and production code
migration will take even longer. Therefore, fixes now are still relevant.
That being said, I agree that fixes addressing odd/unlikely corner-cases
with a measurable performance impact are probably not-desired. My
suggestion is that this is handles on a case-by-case basis, balancing
performance impact to crash likelyhood.

--
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Tue, 08 Sep 2026 12:06:49 +0000

Hello internals,

Over the last few years, more and more issues have been opened where a user defined error handler (or other callbacks) causes a Use After Free (UAF) when said error handler modifiers the variable/property that triggered the warning/deprecation/whatever.
These issues are usually found via fuzzing, or more recently LLMs.

One such example is:

class Victim {
    public $tag = "alive";
    public function target() {
        echo $this->tag;
    }
}

class Holder extends Victim {}

set_error_handler(function ($n, $s) {
    if (str_contains($s, 'Callables of the form')) {
        $GLOBALS['cb'] = null;
        `gc_collect_cycles()`;
    }
    return true;
});

$cb = [new Holder(), 'Victim::target'];
call_user_func($cb); // `SIGSEGV`

(Taken from https://github.com/php/php-src/pull/23014)

Nobody that wants to use PHP to do anything useful would write such an error handler, however mitigating these bugs requires tedious and intrusive fixes usually acting in the following way:

Store the underlying zval value
Increment the refcount of the stored value
Emit the warning/deprecation/whatever
If the zval was modified in some way, restore it (usually) by destroying the new value, or decrement the refcount

This reference tracking dance adds complexity to the engine, but also has negative performance implications for the vast majority of users not doing anything stupid in their error handlers (or other callbacks).
Especially as the most common triggering vector are engine deprecation or warnings that will be remove/promoted to throwing Errors in the future, where it will be very easy to miss removing this refcounting dance.

One potential idea that has been floating around is to delay error handlers. [1]
However, these issue are likely to also happen from other callbacks such as a class autoloader, a tick handler, an output handler, etc. as nothing prevents them from messing around with $GLOBALS or binding a variable to its scope.

While having C memory bugs is far from ideal, the fact that a majority of them will disappear with PHP 9 when deprecation are removed and warnings are promoted to Error makes this whackamole bug chase a waste of time. Especially as these issues have been present for decades and nobody except fuzzers and LLMs have run into these issues.

As such I'd like to hear the opinions of Internals on if we can come to a consensus (ideally without an RFC...) that registering callbacks that mess around with state in non-intended ways is Undefined Behaviour (UB).

While UB is far from desirable, it is not unprecedented in PHP.
Prior to PHP 8, the behaviour of internal functions when given values of invalid types was considered UB, sometimes it returned false, sometimes, null, sometimes it threw an Error.
This was fixed by throwing TypeErrors consistently.

Best regards,

Gina P. Banyard

PS: This is also why removing warnings from the engine by converting them to exceptions is highly desirable, as exceptions have none of these issues as the execution is stopped.
Error handlers specifically run in the middle of an operation which is how they can cause so much chaos. Tick handlers may also have these issues but this might actually be prevented by only calling them at sensible times after an operation has been fully performed.

[1] https://github.com/php/php-src/issues/20018

[RFC] IntlRelativeDateTimeFormatter

Tue, 08 Sep 2026 08:46:35 +0000

Hi Tim,

Yes. The clone was necessary because ICU takes ownership
of the UNumberFormat passed to it.

And yes, this would be unexpected. Technically it is possible
for us to fix this in the php side. My idea is to make the internal
ICU formatter refreshed lazily before the next format() or
formatnumeric() call, and by refreshing we observe if there is
updates to the internal retained numberformatter.

I think this is a good catch user-side. Will add this in the RFC
and implementation. Thanks!

Weilin

[RFC] End PEAR Project Endorsement

Tue, 08 Sep 2026 08:27:38 +0000

Hey Rowan,

In other news, I noticed the mirror you created didn't yet have much styling, so I've put together a quick PR copying in the colours and basic styles from the existing site, plus an idea I had for a "locked PEAR" logo: https://github.com/NickSdot/pear/pull/1

Thanks, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?).

I don't care what the favicon is, as long as there is one.

cheers
Derick

[RFC] IntlRelativeDateTimeFormatter

Tue, 08 Sep 2026 08:12:52 +0000

I am posting this as an "intent to vote" email to announce that
the voting process of this RFC will be opened at 15 Sept if no
further opinions/objections emerge.

Similarly to the PREG_THROW_ON_ERROR one, I didn't yet get around to
this one after my vacation. I've given it a very quick read, but not
much thought. One point for now:

The RFC specifies that the given ICU UNumberFormat is cloned internally.
Does that mean if I pass in a NumberFormatter instance and later
reconfigure using ->setAttribute(), the changes will not be applied to
IntlRelativeDateTimeFormatter? I believe this would be very unexpected
behavior.

Best regards
Tim Düsterhus

[RFC] End PEAR Project Endorsement

Tue, 08 Sep 2026 08:05:02 +0000

I would consider that a Minor change, so 1 week cool down, and you can
post an intent to vote basically any time during that week as it has a
1 week allowance.

I agree. This change in circumstances seems substantial enough that it
might cause folks to vote differently, without changing the actual
proposal.

Best regards
Tim Düsterhus

[RFC] End PEAR Project Endorsement

Tue, 08 Sep 2026 07:55:37 +0000

Hey Rowan,

That's great that someone finally got in touch. Does he have access to provide a database dump, so we can fill in the missing bug data?

That was brought up. Unfortunately, the user accounts are gone. Hence, the bug data cannot be provided.

That's a pity. In hindsight, if we'd acted sooner we could have rescued that content before it disappeared; but we couldn't have known that.

Chuck is the one who had the authority to archive the repos in the PEAR GitHub organisation.

I would make a distinction between technical ability and moral authority. For example, many people have access to commit to the php-src repo; they have the ability to make whatever changes they want, but they only have the authority to make changes within our agreed process.

In this case, Derick has the ability to repoint the DNS for pear.php.net, but holding this discussion and an RFC vote is a way to grant authority.

Chuck has apparently been keeping parts of the PEAR project running after others drifted off, and I thank him for that. If he disagreed with the plan, that would have been significant - but so would anyone replying on the four PEAR mailing lists I posted to last October. Hearing that he is in favour is welcome, but it doesn't change much in terms of moral authority.

Thanks, Rowan! I am fine with that. One thing I'd add: I think having the "locked PEAR" is nice. Not sure about the favicon change. It's will be a The PHP Group hosted archive, not the successor of the PEAR project. Keeping the PHP favicon feels more sound to me, personally. But I happily leave that decision to you and others (infra team?).

Yes, I kept the favicon part in a separate commit in case it was controversial; feel free to cherry-pick the main styling and skip that one if you prefer.

Cheers,

Rowan Tommins
[IMSoP]

[RFC] End PEAR Project Endorsement

Tue, 08 Sep 2026 05:03:08 +0000

Hey Rowan,

That's great that someone finally got in touch. Does he have access to
provide a database dump, so we can fill in the missing bug data?

That was brought up. Unfortunately, the user accounts are gone. Hence,
the bug data cannot be provided.

This is great, because A) everyone involved agrees on the goal and B)
this makes the vote a formality.

Unless you know something I don't, Chuck's agreement is just one vote,
not any kind of final authority. He is listed at
https://pear.php.net/group/ as one of eight members of "the PEAR
Group", so in theory the other seven could decide they want to
continue the project. In fact, the Group was supposed to be re-elected
annually, so even their collective authority is shaky if anyone really
wanted to replace them.

Chuck is the one who had the authority to archive the repos in the PEAR
GitHub organisation.

Also, allow me to highlight the "Non-goals" section of the RFC:

The goal is not to take over the governance of the independent PEAR
package ecosystem. If an independent PEAR team wants to continue PEAR
as an active project, they remain free to do so under domains they control.

In practice, he's the only person involved who anyone has managed to
track down, and even that took several months, so I think we're safe
to say nobody's that interested.

That too, yes.

In other news, I noticed the mirror you created didn't yet have much
styling, so I've put together a quick PR copying in the colours and
basic styles from the existing site, plus an idea I had for a "locked
PEAR" logo: https://github.com/NickSdot/pear/pull/1

Thanks, Rowan! I am fine with that. One thing I'd add: I think having
the "locked PEAR" is nice. Not sure about the favicon change. It's will
be a The PHP Group hosted archive, not the successor of the PEAR
project. Keeping the PHP favicon feels more sound to me, personally. But
I happily leave that decision to you and others (infra team?).

Cheers
Nick

[RFC] End PEAR Project Endorsement

Mon, 07 Sep 2026 22:17:28 +0000

Got news. The tl;dr is that Chuck Burgess from PEAR got in touch with
me (and also Elizabeth from the foundation). He did let me know that
he is good with looking at sunsetting the website and removing PEAR
from PHP source.

That's great that someone finally got in touch. Does he have access to
provide a database dump, so we can fill in the missing bug data?

This is great, because A) everyone involved agrees on the goal and B)
this makes the vote a formality.

Unless you know something I don't, Chuck's agreement is just one vote,
not any kind of final authority. He is listed at
https://pear.php.net/group/ as one of eight members of "the PEAR Group",
so in theory the other seven could decide they want to continue the
project. In fact, the Group was supposed to be re-elected annually, so
even their collective authority is shaky if anyone really wanted to
replace them.

In practice, he's the only person involved who anyone has managed to
track down, and even that took several months, so I think we're safe to
say nobody's that interested.

In other news, I noticed the mirror you created didn't yet have much
styling, so I've put together a quick PR copying in the colours and
basic styles from the existing site, plus an idea I had for a "locked
PEAR" logo: https://github.com/NickSdot/pear/pull/1

Thanks again,

--
Rowan Tommins
[IMSoP]

[RFC] End PEAR Project Endorsement

Mon, 07 Sep 2026 20:37:15 +0000

I would consider that a Minor change, so 1 week cool down, and you can post an intent to vote basically any time during that week as it has a 1 week allowance.

[RFC] End PEAR Project Endorsement

Mon, 07 Sep 2026 19:24:03 +0000

Hey everyone,

I would like to open the discussion to "End PEAR Project Endorsement":
https://wiki.php.net/rfc/end_pear_endorsement

Got news. The tl;dr is that Chuck Burgess from PEAR got in touch with me
(and also Elizabeth from the foundation). He did let me know that he is
good with looking at sunsetting the website and removing PEAR from PHP
source.

This is great, because A) everyone involved agrees on the goal and B)
this makes the vote a formality.

He said he doesn't read here, but anyway from me a thank you to Chuck!

That said, I would soon bring this to vote -- so this mail could be seen
as my "intend to vote" mail. However, there is one detail I would want
to double check with you all. The RFC currently has this sentence:

Attempts to find solutions with PEAR maintainers, directly and
through official channels, did not lead to results.

Given that Chuck now got in touch and is in favour, I am not happy
leaving this sentence unchanged in the RFC. I'd much rather remove it
(or strike it and amend the agreement?).

The question is, when the "Proposal" section remains explicitly
unchanged does it count as a minor change? Given the state of the PEAR
website, and that the vote will be a formality, it would be pity to have
to wait another two weeks to open the vote. Thoughts?

Since this is a policy question I added Tim in CC.

Cheers
Nick

[RFC] IntlRelativeDateTimeFormatter

Mon, 07 Sep 2026 17:19:03 +0000

Hi everyone,

I am posting this as an "intent to vote" email to announce that
the voting process of this RFC will be opened at 15 Sept if no
further opinions/objections emerge.

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

I hope you love this RFC :)

Cheers,
Weilin Du

[RFC][Discussion] Add #[NoSerialize] attribute for excluding properties or classes from serialization

Mon, 07 Sep 2026 13:18:28 +0000

Hi Nicolas,

Thank you for the review, and sorry for the delay.

I checked code bases I know well, Symfony in particular, and I had a
hard time finding any implementation of __serialize()/__sleep() that
the property-level attribute would replace

You are right, and the RFC was wrong to imply otherwise. There is no
such __sleep() in Symfony.

The class-level case is there, six times, written identically in
Lock\Lock, Semaphore\Semaphore, Process\Pipes\UnixPipes,
ErrorHandler\BufferingLogger, HttpClient\Chunk\ErrorChunk and
Form\Util\OrderedHashMapIterator:

public function __serialize(): array
{
    throw new \BadMethodCallException('Cannot serialize '.__CLASS__);
}

For the property-level case, Magento 2 has 31 classes with __sleep(),
chained so that each level strips its own injected services. Each
class below extends the one above it:

Framework\Model\AbstractModel: -8 properties
Framework\Model\AbstractExtensibleModel: -2
Eav\Model\Entity\Attribute\AbstractAttribute: -12
Eav\Model\Entity\Attribute: -4
Catalog\Model\ResourceModel\Eav\Attribute: -4

Every level is array_diff(parent::__sleep(), [...]) with a mirrored
__wakeup() re-injecting the same services, so each property is named
twice. Same shape in their collection hierarchy, in Store and in User
(13 properties). Smaller whitelist form: Laravel's RateLimited and
Doctrine's PersistentCollection.

having objects that embed both value-state and a PDO connection looks like a design smell

Agreed as a principle, and PDO was a bad headline example. But this is
the normal shape of an ORM model in Magento and Laravel, and it will
not be redesigned away. __serialize() is not a substitute: it requires
describing the whole format by hand, which is what produces those
array_diff() chains.

The introduction has been rewritten around these examples.

contracts propagate naturally to child classes. Attributes don't, and
making this one an exception raises the question: why break attribute
rules

It is not an exception. #[AllowDynamicProperties] already behaves this
way, since 8.2:

#[AllowDynamicProperties]
class P {}
class C extends P {}

$c = new C;
$c->dyn = 1;                 // no deprecation: flag is inherited
$r = new ReflectionClass('C');
$r->getAttributes(AllowDynamicProperties::class);   // array(0) {}

zend_inheritance.c copies ZEND_ACC_ALLOW_DYNAMIC_PROPERTIES from the
parent, alongside ZEND_ACC_NOT_SERIALIZABLE.

The interface alternative was argued at length in the 2024 thread and
the list did not converge: Eberlei, Banyard and Dusk for the
attribute, you and Larry for the interface.

One cost that was not raised there: this RFC migrates 107 internal
classes across 64 stub files. As an interface, all of them would gain
a new entry in class_implements() — observable userland state, and a
larger BC surface than an attribute.

If the list prefers an interface, that is the list's call, but it
should be made deliberately rather than as a side effect here.

we would need reflection-based checks on every property during both
serialization and unserialization

I checked var-exporter. The cost is per-class on 7.x, and on 8.1 it is
not reflection at all.

Class-level is free: it sets the existing ZEND_ACC_NOT_SERIALIZABLE.
On 7.x Registry::unserialize() calls native unserialize(), which
already guards that flag, and getClassReflector() probes with
serialize($proto) once per class. ext-deepclone tests the flag
directly (deepclone.c:519, :5234).

Property-level on 8.1: VarExporter::export() delegates to
deepclone_to_array(), whose fast path already iterates
ce->properties_info_table and tests prop_info->flags —
ZEND_ACC_STATIC, ZEND_ACC_PUBLIC, ZEND_ACC_PROTECTED_SET,
ZEND_ACC_PRIVATE_SET (deepclone.c:2453-2489). ZEND_ACC_NO_SERIALIZE is
one more condition in a loop that already runs. The polyfill does use
reflection, but per class on both sides: $scopeMaps for export
(DeepClone.php:785-795), $propertyScopes for hydration (:453).

For the engine the comparison runs the other way: a ce_flags bit test
is cheaper than instanceof, which is why the engine uses a flag.

Three changes to the RFC since your message:

The introduction cites the codebases above instead of asserting that
the use case is common.
Internal classes are migrated explicitly, as @deprecated was
migrated to #[\Deprecated] in 8.4, rather than having the attribute
injected during code generation. @not-serializable stays supported for
third-party extensions. This follows Tim's suggestion.
unserialize() is now symmetric: a #[NoSerialize] property present in
the payload is parsed and discarded rather than restored. The
attribute now means "not part of the serialized form" in both
directions, matching transient in Java and [NonSerialized] in C#, and
removing an injection surface. The old behaviour is recorded under
Rejected Features.

Best regards,
Dmytro Kulyk

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 07 Sep 2026 13:04:49 +0000

I think there might be a misunderstanding based on how you phrased that
paragraph. To provide a more specific example:

Sorry - I think I might have just worded my message poorly, as your
more detailed example is how I understood the RandomException to
look like. I think the core is that in both cases; but specifically
with the session example, the action is what has failed (and
regardless of cause then it is desired to have a single catch to
handle that).

preg_replace_callback() is different in that I explicitly pass in a
callback and thus I'm technically in full control over the code that is
being executed and I can theoretically know what exceptions could
possibly be thrown and might intentionally want to handle them
explicitly

Looking at this from a different angle - the first part (in that the
developer is in full control of the code) might be the most important
part here. If the developer wants any failure (a non-zero
preg_last_error() result or an error that occurs during the
callback) to have a single catch block then the developer is able to
throw a PregException themselves (or a child of PregException).

However if PregException wraps any Throwables in the userland
callbacks, a developer who wants to have multiple catch blocks (or
throw some exceptions that propagate to a higher scope in their
callback) can only do that by catching and rethrowing.

Hi

Arguably this specific case is a bit debatable, but as the author of
the
throwable policy RFC, I believe that it is at least violated in
spirit.
The goal of the throwable policy generally, and also with regard to
that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block.

Obviously you wrote the policy and so are best placed to interpret it
(and I am not a core developer / person with voting rights); however I
agree with the angle Osama is coming from here - I wouldn't say this
is an error that is (always) part of the same group. There wasn't any
error in the call to preg_replace_callback itself (or any of its
functionality) - the error was in a way during the processing of the

Yes, I agree that this case is not entirely clear-cut - and it's good
we're having this discussion now.

If I have understood the other example correctly, this contradicts
quite significantly with the CSPRNG throwing an Exception that
RandomException contains - as the failure is a core issue within the
function call itself as opposed to logic that occurs in userland.

I think there might be a misunderstanding based on how you phrased that
paragraph. To provide a more specific example:

Consider I have a session implementation that uses Redis as its session
storage backend. Session IDs need to be created using secure randomness,
i.e. using the CSPRNG. Both the Redis backend and the CSPRNG can
theoretically fail. As a user when create a new session I want to be
able to just catch (SessionInitializedFailedException) and not care
about whether the CSPRNG or the Redis connection failed, and I might not
even know if it's Redis, Memcache, a File System or a MySQL database.
Thus any underlying issues must be wrapped into a session-specific
exception.

preg_replace_callback() is different in that I explicitly pass in a
callback and thus I'm technically in full control over the code that is
being executed and I can theoretically know what exceptions could
possibly be thrown and might intentionally want to handle them
explicitly. On the other hand, failing to execute the callback means
that the replacing operation failed, no further callbacks will be called
and preg_replace_callback() will not return anything - and that is a
“running this regex failed” a.k.a. PregException situation to me.

If anything, I would argue that under the policy this should go the
other way and become PregError:

The Error hierarchy MUST NOT be used for errors that are expected to
be thrown (and caught) during normal operation of a PHP program.
In terms of the possible errors that could occur, I would expect at
least PREG_INTERNAL_ERROR, PREG_BAD_UTF8_ERROR &
PREG_JIT_STACKLIMIT_ERROR to be code errors that require a developer
to need to correct their code (as my understanding of these would be
that the pattern is invalid, or not quoted correctly, etc. Although
PREG_BACKTRACK_LIMIT_ERROR & PREG_RECURSION_LIMIT_ERROR are more
likely to occur based on user input, then the limit for both is
controlled by an ini setting - so again, this likely isn't something I
would say is expected to be thrown and caught during normal operation
of a PHP program. The final error (PREG_BAD_UTF8_OFFSET_ERROR) I
think would still likely need a code change to fix it occurring -
although I have only done a quick Google to see when it may occur.

This is a good point. I agree that things like pattern compilation
failures should be a PregError, since this is a clear programmer error
and regular expressions are not supposed to be untrusted inputs. For the
error error situations I would need to check as well if they are
expected during regular operation or not. The backtrack or recursion
limits I can see being caught intentionally to provide better error
messages to a user (thus PregException).

Best regards
Tim Düsterhus

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 07 Sep 2026 12:31:23 +0000

Arguably this specific case is a bit debatable, but as the author of
the
throwable policy RFC, I believe that it is at least violated in
spirit.
The goal of the throwable policy generally, and also with regard to
that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block.

Obviously you wrote the policy and so are best placed to interpret it
(and I am not a core developer / person with voting rights); however I
agree with the angle Osama is coming from here - I wouldn't say this
is an error that is (always) part of the same group. There wasn't any
error in the call to preg_replace_callback itself (or any of its
functionality) - the error was in a way during the processing of the

Yes, I agree that this case is not entirely clear-cut - and it's good
we're having this discussion now.

If I have understood the other example correctly, this contradicts
quite significantly with the CSPRNG throwing an Exception that
RandomException contains - as the failure is a core issue within the
function call itself as opposed to logic that occurs in userland.

I think there might be a misunderstanding based on how you phrased that
paragraph. To provide a more specific example:

Consider I have a session implementation that uses Redis as its session
storage backend. Session IDs need to be created using secure randomness,
i.e. using the CSPRNG. Both the Redis backend and the CSPRNG can
theoretically fail. As a user when create a new session I want to be
able to just catch (SessionInitializedFailedException) and not care
about whether the CSPRNG or the Redis connection failed, and I might not
even know if it's Redis, Memcache, a File System or a MySQL database.
Thus any underlying issues must be wrapped into a session-specific
exception.

preg_replace_callback() is different in that I explicitly pass in a
callback and thus I'm technically in full control over the code that is
being executed and I can theoretically know what exceptions could
possibly be thrown and might intentionally want to handle them
explicitly. On the other hand, failing to execute the callback means
that the replacing operation failed, no further callbacks will be called
and preg_replace_callback() will not return anything - and that is a
“running this regex failed” a.k.a. PregException situation to me.

If anything, I would argue that under the policy this should go the
other way and become PregError:

The Error hierarchy MUST NOT be used for errors that are expected to
be thrown (and caught) during normal operation of a PHP program.
In terms of the possible errors that could occur, I would expect at
least PREG_INTERNAL_ERROR, PREG_BAD_UTF8_ERROR &
PREG_JIT_STACKLIMIT_ERROR to be code errors that require a developer
to need to correct their code (as my understanding of these would be
that the pattern is invalid, or not quoted correctly, etc. Although
PREG_BACKTRACK_LIMIT_ERROR & PREG_RECURSION_LIMIT_ERROR are more
likely to occur based on user input, then the limit for both is
controlled by an ini setting - so again, this likely isn't something I
would say is expected to be thrown and caught during normal operation
of a PHP program. The final error (PREG_BAD_UTF8_OFFSET_ERROR) I
think would still likely need a code change to fix it occurring -
although I have only done a quick Google to see when it may occur.

This is a good point. I agree that things like pattern compilation
failures should be a PregError, since this is a clear programmer error
and regular expressions are not supposed to be untrusted inputs. For the
error error situations I would need to check as well if they are
expected during regular operation or not. The backtrack or recursion
limits I can see being caught intentionally to provide better error
messages to a user (thus PregException).

Best regards
Tim Düsterhus

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 07 Sep 2026 11:58:51 +0000

Arguably this specific case is a bit debatable, but as the author of the
throwable policy RFC, I believe that it is at least violated in spirit.
The goal of the throwable policy generally, and also with regard to that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block.

Obviously you wrote the policy and so are best placed to interpret it
(and I am not a core developer / person with voting rights); however I
agree with the angle Osama is coming from here - I wouldn't say this
is an error that is (always) part of the same group. There wasn't any
error in the call to preg_replace_callback itself (or any of its
functionality) - the error was in a way during the processing of the
result of the function. Taking your example - what if instead of
CustomException you had InvalidLengthException,
IncorrectFormatException, NotKnownBIN, etc. Instead of being able
to catch say InvalidLengthException & IncorrectFormatException to
return a validation error asking the user to check their input;
NotKnownBIN to return that the user can not use that particular card
with you, and PregException to note a system failure occurred then
you have to catch PregException (or Exception) and then use
switch / match on $previous.

If I have understood the other example correctly, this contradicts
quite significantly with the CSPRNG throwing an Exception that
RandomException contains - as the failure is a core issue within the
function call itself as opposed to logic that occurs in userland.

If anything, I would argue that under the policy this should go the
other way and become PregError:

The Error hierarchy MUST NOT be used for errors that are expected to be thrown (and caught) during normal operation of a PHP program.
In terms of the possible errors that could occur, I would expect at
least PREG_INTERNAL_ERROR, PREG_BAD_UTF8_ERROR &
PREG_JIT_STACKLIMIT_ERROR to be code errors that require a developer
to need to correct their code (as my understanding of these would be
that the pattern is invalid, or not quoted correctly, etc. Although
PREG_BACKTRACK_LIMIT_ERROR & PREG_RECURSION_LIMIT_ERROR are more
likely to occur based on user input, then the limit for both is
controlled by an ini setting - so again, this likely isn't something I
would say is expected to be thrown and caught during normal operation
of a PHP program. The final error (PREG_BAD_UTF8_OFFSET_ERROR) I
think would still likely need a code change to fix it occurring -
although I have only done a quick Google to see when it may occur.

I do admit that overall - my only real experience with the preg_*
functions erroring is where the pattern itself is not valid in some
way; so there may be more common use-cases that fit the exception path

but hopefully explaining why my viewpoint is to treat it as an
Error hierarchy Throwable as opposed to Exception covers why not
wrapping any throws from the userland callbacks makes sense.

Hi

Now what I would suggest instead of breaking that guarantee, is to pull
enriching the anemic preg_last_error_msg() error message forward into
this RFC instead of leaving it for later, store the real reason in the
error state, and the exception inherits it through the very same channel,
with the guarantee intact.

That would also work for me. But the E_WARNING should remain when the
PREG_THROW_ON_ERROR flag is not set, because some users might rely on
the warning being emitted to turn it into an Exception themselves by
means of an error handler.

What is important to me is that the new flag cleanly results in an
Exception and only an Exception for all possible errors, because this is
what users will expect from it.
On your second point, if this is a violation of a policy, then there isn't
much to argue. I will just retract the vote and fix that.

But I think I got confused here, and I would appreciate you explaining how
that violates the policy.

To make sure we're on the same ground, this is what I understood from your
statement about wrapping exceptions thrown in user callbacks:
preg_replace_callback(
     $pattern,
     fn () => throw new CustomException(), // <- You want this wrapped in
PregException?
     $subject,
     flags: PREG_THROW_ON_ERROR,
);
Yes. I expect a PregException where $e->getPrevious() instanceof
CustomException().

If I got it right (and I suspect I did), then how does that violate the
policy?
A user callback isn't external functionality, is it? Because as far as I
understand, external functionality is something the extension itself
depends on as part of its own implementation.

Arguably this specific case is a bit debatable, but as the author of the
throwable policy RFC, I believe that it is at least violated in spirit.

The goal of the throwable policy generally, and also with regard to that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block. Consider this:
 try {
     $contents = get_from_api('http://example.com');

     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );

     echo $contents;
 } catch (PregException $e) {
     echo "Sanitization failed\n";
 } catch (HttpException $e) {
     echo "Download failed\n";
 }
I am catching the PregException to handle failures during the credit
card sanitization step. If mask_credit_card() throws its own exception
that is not wrapped, my catch blocks are insufficient and I would
instead need to write it something like this:
 try {
     $contents = get_from_api('http://example.com');
 } catch (HttpException $e) {
     echo "Download failed\n";
     return;
 }
 try {
     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );
 } catch (Exception $e) {
     echo "Sanitization failed\n";
     return;
 }
 echo $contents;
To reliably handle just the exceptions that happen during sanitization
and nothing else. This is a lot of extra boilerplate code and noise.

Now if I am still interested in the inner exception for the callback
failure, something like this would work:
 } catch (PregException $e) {
     if ($e->getCode() === PregException::CALLBACK_FAILURE) {
         echo "Sanitization callback failed: ",
$e->getPrevious()->getMessage();
} else {
echo "Sanitization failed\n";
}
}

Because if the error code is callback failure, I know that there is a
previous Exception. So I don't lose any functionality / information.

I am also unaware of any functions that behave like that (wraps exceptions
thrown in user callbacks in its own exception).

There are a few cases where the CSPRNG (which throws RandomException on
failure) is used internally and the exception on CSPRNG failure is
wrapped. However much of the standard library predates the throwable
policy (which was accepted in May 2025;
https://wiki.php.net/rfc/extension_exceptions), that's why it doesn't
follow it.

In fact, the opposite is the case for one of the precedents this RFC
follows (json_encode() with JSON_THROW_ON_ERROR - although it doesn't
accept a user callback): https://3v4l.org/CtHYH#v8.5.10

Yes, that flag and JsonSerializable itself is much older than the policy.

Best regards
Tim Düsterhus

[RFC] End PEAR Project Endorsement

Mon, 07 Sep 2026 09:03:46 +0000

We win nothing by further stalling a decision; I believe we should
stop the endorsement for PEAR.

I think this is the key: a lot of the comments on previous discussions
were about "giving a chance" for one or other individual or group to
revive the website. Multiple attempted contacts were made, and many
months have gone by, with nobody reporting a positive result.

If that's not long enough, how long is? If the site stays alive in its
current state for 10 years, it will continue to be exploited by
spammers and probably worse. That's not in anyone's interest.

Coincidentally, Andrew Nesbitt, who writes tooling and analysis
comparing different packaging systems, wrote a recent post about
approaches to sunsetting:
https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html

One of the points he discusses is that freezing a channel rather than
taking it offline means that security vulnerabilities are also frozen
in place, with no way to supersede them for anyone still using the old
tooling.

I think readonly is probably the right approach in this case at least
in the short term, but actively sunsetting later is maybe something to
consider.

I agree. I think we should commit to leaving it on for a specified
amount only (a year), and then also turn off the archival variant of the
site. We can move a tarball onto our museum.php.net property for
archeologists.

cheers,
Derick

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 07 Sep 2026 05:16:10 +0000

Hi

Now what I would suggest instead of breaking that guarantee, is to pull
enriching the anemic preg_last_error_msg() error message forward into
this RFC instead of leaving it for later, store the real reason in the
error state, and the exception inherits it through the very same channel,
with the guarantee intact.

That would also work for me. But the E_WARNING should remain when the
PREG_THROW_ON_ERROR flag is not set, because some users might rely on
the warning being emitted to turn it into an Exception themselves by
means of an error handler.

What is important to me is that the new flag cleanly results in an
Exception and only an Exception for all possible errors, because this is
what users will expect from it.
On your second point, if this is a violation of a policy, then there isn't
much to argue. I will just retract the vote and fix that.

But I think I got confused here, and I would appreciate you explaining how
that violates the policy.

To make sure we're on the same ground, this is what I understood from your
statement about wrapping exceptions thrown in user callbacks:
preg_replace_callback(
     $pattern,
     fn () => throw new CustomException(), // <- You want this wrapped in
PregException?
     $subject,
     flags: PREG_THROW_ON_ERROR,
);
Yes. I expect a PregException where $e->getPrevious() instanceof
CustomException().

If I got it right (and I suspect I did), then how does that violate the
policy?
A user callback isn't external functionality, is it? Because as far as I
understand, external functionality is something the extension itself
depends on as part of its own implementation.

Arguably this specific case is a bit debatable, but as the author of the
throwable policy RFC, I believe that it is at least violated in spirit.

The goal of the throwable policy generally, and also with regard to that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block. Consider this:
 try {
     $contents = get_from_api('http://example.com');

     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );

     echo $contents;
 } catch (PregException $e) {
     echo "Sanitization failed\n";
 } catch (HttpException $e) {
     echo "Download failed\n";
 }
I am catching the PregException to handle failures during the credit
card sanitization step. If mask_credit_card() throws its own exception
that is not wrapped, my catch blocks are insufficient and I would
instead need to write it something like this:
 try {
     $contents = get_from_api('http://example.com');
 } catch (HttpException $e) {
     echo "Download failed\n";
     return;
 }
 try {
     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );
 } catch (Exception $e) {
     echo "Sanitization failed\n";
     return;
 }
 echo $contents;
To reliably handle just the exceptions that happen during sanitization
and nothing else. This is a lot of extra boilerplate code and noise.

Now if I am still interested in the inner exception for the callback
failure, something like this would work:
 } catch (PregException $e) {
     if ($e->getCode() === PregException::CALLBACK_FAILURE) {
         echo "Sanitization callback failed: ",
$e->getPrevious()->getMessage();
} else {
echo "Sanitization failed\n";
}
}

Because if the error code is callback failure, I know that there is a
previous Exception. So I don't lose any functionality / information.

I am also unaware of any functions that behave like that (wraps exceptions
thrown in user callbacks in its own exception).

There are a few cases where the CSPRNG (which throws RandomException on
failure) is used internally and the exception on CSPRNG failure is
wrapped. However much of the standard library predates the throwable
policy (which was accepted in May 2025;
https://wiki.php.net/rfc/extension_exceptions), that's why it doesn't
follow it.

In fact, the opposite is the case for one of the precedents this RFC
follows (json_encode() with JSON_THROW_ON_ERROR - although it doesn't
accept a user callback): https://3v4l.org/CtHYH#v8.5.10

Yes, that flag and JsonSerializable itself is much older than the policy.

Best regards
Tim Düsterhus

Hi Tim,

Thank you for the elaboration.

The first thing that came to my mind reading your example is that
without wrapping, an extra catch block would be enough:

try {
    $contents = get_from_api('http://example.com');

    $contents = preg_replace_callback(
        '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
        function ($matches) {
            return mask_credit_card($matches[0]); // throws MaskException
        },
        $contents,
        flags: PREG_THROW_ON_ERROR,
    );

    echo $contents;
} catch (MaskException $e) {
    echo "Sanitization failed\n";
} catch (PregException $e) {
    echo "Regex failed\n";
} catch (HttpException $e) {
    echo "Download failed\n";
}

The caveat of course is that this only works when you know the
exception a callback can throw...which you don't always control.

But since you've made clear this is a violation of the throwable
policy, I've retracted the vote until we get it resolved.

Following the idea of wrapping the callback's exception, I see two problems...
One is a footgun I'd want explicitly addressed.
The other, I'm afraid, forces an exception hierarchy in place of a
single PregException.

First...wrapping couples the exception you catch to the flag.
Without it, preg_replace_callback() throws whatever the callback throws.
With it, the same call always throws a PregException.
So the flag silently changes which exception a caller has to handle,
and the two have to move together:

try {
    preg_replace_callback(
        '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
        function ($matches) {
            return mask_credit_card($matches[0]); // throws MaskException
        },
        $contents,
    );
} catch (MaskException $e) {
    // becomes dead the moment the flag is added, and comes back the
moment it's removed
}

Second...wrapping a callback's exception in a PregException produces
a PregException that maps to no preg error.
You can be holding a PregException while preg_last_error() and
preg_last_error_msg() report no error at all. That is an exception
whose type says a regex error happened when, by preg's own state, none
did.
This is separate from the $e->getMessage() === preg_last_error_msg()``
guarantee I raised before. Even setting that aside, it's incoherent on
its own terms, because the flag is PREG_THROW_ON_ERROR and
preg_last_error() is what an error is.

So keeping that honest means a bare PregException can no longer
stand for two different things at once.
So it has to split into a PregPcreException (or a better name)
carrying the real preg error and mirroring preg_last_error()...and
PregCallbackException wrapping the callback's exception. And then to
satisfy the single catch both would need to extend a shared
PregException parent.
That's a whole hierarchy to carry a case an extra catch would have handled.

So the cost of wrapping comes out as a silent footgun plus a
three-class hierarchy, for what one more catch could do.
Both look intrinsic to wrapping, though. The footgun is the flip side
of the single catch you want, and the hierarchy is what keeps that
catch honest, so neither can really be designed away.

That is if I didn't miss anything along the way...

So my question now is: is that price worth paying over the extra
catch...or is the extra catch acceptable after all?
That's where I'd hope your "Arguably this specific case is a bit
debatable" leaves some room.

In any case...I'll be working on how the preg_last_error_msg()
change impacts the RFC, and meanwhile looking for opinions on the
wrapping points I've raised above.

Regards,
Osama

[RFC] [VOTE] PREG_THROW_ON_ERROR

Mon, 07 Sep 2026 00:35:01 +0000

Hi all,

The discussion period for PREG_THROW_ON_ERROR has passed with no open issues, so I'm opening the vote.

Recap: the RFC adds an opt-in PREG_THROW_ON_ERROR flag.
Pass it to any preg_* matching function and any PCRE error the call records is additionally thrown as a \PregException, so you can catch it instead of checking the return value.
The exception's code and message match preg_last_error() and preg_last_error_msg() exactly, and a call without the flag behaves exactly as it does today.

RFC: https://wiki.php.net/rfc/preg_throw_on_error
PR: https://github.com/php/php-src/pull/22797

Voting is open now and closes on 2026-09-18 17:00:00 UTC.

Regards,
Osama

Hi everyone,

I'm cancelling the vote on PREG_THROW_ON_ERROR.

The flag as it stands violates the throwable policy, as Tim's point shows.
That's not something to fix with the vote open, so I'm pulling it back
rather than changing the proposal out from under people who already
voted.

I'll keep the discussion here, and once things settle I'll start a fresh vote.
The RFC is back under discussion.

Thanks to Tim for catching this before it went further.

Regards,
Osama

[RFC] [VOTE] PREG_THROW_ON_ERROR

Sun, 06 Sep 2026 11:59:52 +0000

Now what I would suggest instead of breaking that guarantee, is to pull
enriching the anemic preg_last_error_msg() error message forward into
this RFC instead of leaving it for later, store the real reason in the
error state, and the exception inherits it through the very same channel,
with the guarantee intact.

That would also work for me. But the E_WARNING should remain when the
PREG_THROW_ON_ERROR flag is not set, because some users might rely on
the warning being emitted to turn it into an Exception themselves by
means of an error handler.

What is important to me is that the new flag cleanly results in an
Exception and only an Exception for all possible errors, because this is
what users will expect from it.

On your second point, if this is a violation of a policy, then there isn't
much to argue. I will just retract the vote and fix that.

But I think I got confused here, and I would appreciate you explaining how
that violates the policy.

To make sure we're on the same ground, this is what I understood from your
statement about wrapping exceptions thrown in user callbacks:
preg_replace_callback(
     $pattern,
     fn () => throw new CustomException(), // <- You want this wrapped in
PregException?
     $subject,
     flags: PREG_THROW_ON_ERROR,
);

Yes. I expect a PregException where $e->getPrevious() instanceof
CustomException().

If I got it right (and I suspect I did), then how does that violate the
policy?
A user callback isn't external functionality, is it? Because as far as I
understand, external functionality is something the extension itself
depends on as part of its own implementation.

Arguably this specific case is a bit debatable, but as the author of the
throwable policy RFC, I believe that it is at least violated in spirit.

The goal of the throwable policy generally, and also with regard to that
specific paragraph is to allow reliably handling groups of errors
without needing to wrap every individual statement into its own
try-catch block. Consider this:

 try {
     $contents = get_from_api('http://example.com');

     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );

     echo $contents;
 } catch (PregException $e) {
     echo "Sanitization failed\n";
 } catch (HttpException $e) {
     echo "Download failed\n";
 }

I am catching the PregException to handle failures during the credit
card sanitization step. If mask_credit_card() throws its own exception
that is not wrapped, my catch blocks are insufficient and I would
instead need to write it something like this:

 try {
     $contents = get_from_api('http://example.com');
 } catch (HttpException $e) {
     echo "Download failed\n";
     return;
 }
 try {
     // sanitize credit card numbers
     $contents = preg_replace_callback(
         '/[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}/',
         function ($matches) {
             return mask_credit_card($matches[0]);
         },
         $contents,
         falgs: PREG_THROW_ON_ERROR,
     );
 } catch (Exception $e) {
     echo "Sanitization failed\n";
     return;
 }
 echo $contents;

To reliably handle just the exceptions that happen during sanitization
and nothing else. This is a lot of extra boilerplate code and noise.

Now if I am still interested in the inner exception for the callback
failure, something like this would work:

 } catch (PregException $e) {
     if ($e->getCode() === PregException::CALLBACK_FAILURE) {
         echo "Sanitization callback failed: ",

$e->getPrevious()->getMessage();
} else {
echo "Sanitization failed\n";
}
}

Because if the error code is callback failure, I know that there is a
previous Exception. So I don't lose any functionality / information.

I am also unaware of any functions that behave like that (wraps exceptions
thrown in user callbacks in its own exception).

There are a few cases where the CSPRNG (which throws RandomException on
failure) is used internally and the exception on CSPRNG failure is
wrapped. However much of the standard library predates the throwable
policy (which was accepted in May 2025;
https://wiki.php.net/rfc/extension_exceptions), that's why it doesn't
follow it.

In fact, the opposite is the case for one of the precedents this RFC
follows (json_encode() with JSON_THROW_ON_ERROR - although it doesn't
accept a user callback): https://3v4l.org/CtHYH#v8.5.10

Yes, that flag and JsonSerializable itself is much older than the policy.

Best regards
Tim Düsterhus

[RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Sat, 05 Sep 2026 16:02:42 +0000

Hi Ignace,
Some context: I maintain libraries including spomky-labs/base64url, two one-line
functions with 46M downloads. So, strong +1 on getting this into core.

Two gaps in DecodingMode::Strict I would like closed, both verified on 8.5:

    // whitespace is skipped, even in strict mode
    base64_decode("QUJD\nRA==", true);                            // "ABCD"


    // non-canonical trailing bits are discarded, not checked
    base64_decode('QQ==', true) === base64_decode('QR==', true);  // true

The RFC keeps whitespace ignored "independent of the mode", but sections
3.1 and 3.3 say the opposite, and in JOSE the signature covers the exact
string received, so skipping whitespace decouples what was verified from
what was decoded. Section 3.5 then lets a decoder reject non-zero pad
bits, and Strict is where that belongs: sixteen strings decode to any
one-byte tail, four to any two-byte tail. WebAuthn credential IDs and JWT
kid values are used as database keys, so that is sixteen spellings of one
credential, fifteen of them outside your unique index.

Smaller point: please state explicitly that Base64::UrlSafe accepts padded
and unpadded input under Strict, and that PreservePadding with it is not a
ValueError. Padded base64url is legal per section 5 and does show up in
the wild.

Happy to help on the base64 implementation and to bring test vectors;
between JOSE, WebAuthn and COSE I have a fairly nasty corpus of
real-world base64url.

Best regards

Florent Morselli

Le samedi 5 septembre 2026 à 17:59, ignace nyamagana butera nyamsprod@gmail.com a écrit :

Hi all,
Since my last reply I have updated the RFC:

RFC Text: https://wiki.php.net/rfc/data_encoding_api

Discussion Thread: https://news-web.php.net/php.internals/128069

The main changes are:

I added functions for base58 and base85 encoding;

For completeness, I introduced an error marker class (as per PHP policies) and a specific exception to handle potential encoding errors;

I added examples to better explain the expected behaviours during string process;

I have updated the migration path from the current/legacy API to the newly proposed API;

Best regards,
Ignace

[RFC] OpenSSL provider-based algorithms and post-quantum cryptography support

Sat, 05 Sep 2026 10:57:56 +0000

I am happy to work on the RFC, API design, documentation and testing,
and to help with the implementation where I can. I would particularly
appreciate involvement from someone already working on ext/openssl for
the actual C implementation.

I am currently preparing an RFC and would especially appreciate feedback
from people familiar with ext/openssl on the general direction and API
design before finalizing the proposal.

In particular, I'd be interested in opinions on whether provider-based
key support and the KEM API should be addressed in a single RFC or split
into separate proposals.

Hi Timo,
Sebastian sent an email a while ago with similar motivation. It
unfortunately did not get any traction, but I'm glad this was brought
up again:

https://externals.io/message/130673

Similar to how ext-curl integrates libcurl into PHP, I personally
believe that, ideally, ext-openssl should remain as close as possible
to OpenSSL, without introducing our own APIs. Userland libraries can
abstract the complexities and provide purpose-built and intuitive
APIs. This simplifies our work in the integration, and provides an
easy verification path for ext-openssl development.

ext-openssl not only lacks PQC APIs, but also several other features
and changes introduced in OpenSSL 3.5 and 4. It can be quite a big
task, and I'd be really happy to help in any ways I can too.

Thank you,
Ayesh.

[RFC] OpenSSL provider-based algorithms and post-quantum cryptography support

Sat, 05 Sep 2026 10:05:49 +0000

Hi internals,

I'd like to start a discussion about improving support for modern
OpenSSL provider-based asymmetric algorithms in ext/openssl, in
particular post-quantum cryptography (PQC).

This is related to the following existing issues:

https://github.com/php/php-src/issues/22862
https://github.com/php/php-src/issues/23421

With recent OpenSSL versions, standardized post-quantum algorithms such
as ML-KEM, ML-DSA and SLH-DSA are available through the EVP/provider APIs.

However, PHP's OpenSSL extension currently exposes asymmetric
cryptography largely through a fixed set of OPENSSL_KEYTYPE_* constants
and does not expose the generic KEM encapsulation/decapsulation
operations provided by OpenSSL.

Rather than adding individual PHP constants and APIs for each PQC
algorithm, I would like to explore exposing the underlying OpenSSL
provider model more generically.

The initial idea is to cover:

asymmetric key generation using an OpenSSL algorithm name;
provider-backed algorithms which do not have a dedicated
OPENSSL_KEYTYPE_* constant;
generic KEM encapsulation and decapsulation;
support for provider-backed signature algorithms such as ML-DSA and
SLH-DSA through the existing signing APIs where possible.

An important goal would be to keep this generic rather than making the
PHP API specific to ML-KEM or other currently standardized PQC
algorithms. This would allow future algorithms and potentially
third-party OpenSSL providers to use the same API.

I should also mention that I am probably not the right person to
implement the C side of this proposal myself. My C experience is
somewhat rusty and, given that this concerns security-sensitive
cryptographic functionality, I would strongly prefer the implementation
to be done or at least closely guided and reviewed by someone who is
already familiar with ext/openssl and its internals.

From my current understanding, the implementation effort should be
relatively contained, since the cryptographic primitives themselves are
already implemented by OpenSSL. The main task would be exposing the
corresponding existing EVP/provider functionality through ext/openssl
and integrating it consistently with PHP's existing OpenSSL APIs.

That said, I don't want to underestimate the details involved in safely
exposing these APIs, particularly around key handling, provider
compatibility, error handling and maintaining compatibility with the
OpenSSL versions supported by PHP.

I am happy to work on the RFC, API design, documentation and testing,
and to help with the implementation where I can. I would particularly
appreciate involvement from someone already working on ext/openssl for
the actual C implementation.

I am currently preparing an RFC and would especially appreciate feedback
from people familiar with ext/openssl on the general direction and API
design before finalizing the proposal.

In particular, I'd be interested in opinions on whether provider-based
key support and the KEM API should be addressed in a single RFC or split
into separate proposals.

Thanks,
Timo

[RFC] [VOTE] PREG_THROW_ON_ERROR

Fri, 04 Sep 2026 23:53:31 +0000

Hi Tim,

I regretfully were not able to work through the list backlog after my
summer vacation and thus also missed the intent to vote. I have just
read through the RFC and voted against it, despite being in agreement of
the general concept.

No worries at all. I'd already read the quiet on the thread as people being
busy rather than as sign-off, so I'm glad it came when it did.
I'd rather get this right than get it fast.

Specifically:

I disagree with keeping the Warning on compilation errors. This
feature is entirely new and opt-in, thus there are no backwards
compatibility expectations or considerations. The $e->getMessage() === preg_last_error_msg()`` guarantee makes the feature much worse than it
could be for compilation errors. Including all necessary information in
the Exception is a must for me.

On your first point, I think I can safely claim that I understand exactly
where you're coming from, because what you're describing was what I
actually chose first.

What moved me off it was a single decision that I had to make later when I
faced the array case^1 about whether this flag should add error semantics
of its own, or only deliver the error the call already recorded via an
exception.

I chose the second, and the reasons for the warning/error messages case
were:

The detailed compile message isn't in the error state to begin with.
When a pattern fails to compile, the error from
pcre2_get_error_message() only ever goes into the E_WARNING and is then
thrown away. To put that detail in the exception, we must store it
somewhere first.
It would make the flag the one place in ext/pcre that knows more
about the error than preg_last_error_msg() does.
The better fix, which resolves the two issues above, is to repair the
anemic message at its source, in preg_last_error_msg() itself, store the
real reason in the error state for compile errors, and the exception just
inherits it, with no new flag behavior at all.
But that would widen the scope of the RFC from just a flag that throws
an exception, to also changing the message returned by
preg_last_error_msg().

For those reasons, I chose the $e->getMessage() === preg_last_error_msg()``
guarantee to keep things consistent, and I chose to push changing the
preg_last_error_msg() error message into future work.

To me that's also the better separation of concerns.
Letting the exception report exactly what preg_last_error_msg() reports
buys two things:

Consistency: one error, one message, whether you read it from the
exception or from the function.
The anemic message gets fixed where it actually originates.
Because if $e->getMessage() returning "Internal error" is a problem,
then preg_last_error_msg() returning "Internal error" is the same
problem, and it's worth fixing there rather than papering over it on the
exception alone.

So while I agree all the necessary information should typically be in the
exception, I don't want to get there by breaking the $e->getMessage() === preg_last_error_msg()`` guarantee.

Now what I would suggest instead of breaking that guarantee, is to pull
enriching the anemic preg_last_error_msg() error message forward into
this RFC instead of leaving it for later, store the real reason in the
error state, and the exception inherits it through the very same channel,
with the guarantee intact.

I know this is arguably its own debate, but I am more ok with that than
introducing what I think is an inconsistency.

I disagree with the behavior of not wrapping Exceptions thrown in
user callbacks: I believe the correct choice is to throw a
\PregException with the Exception thrown in the callback as the
->previous exception. Not wrapping the user callback exception means
that one needs a catch(Exception) with a try just around the preg_
call to reliably handle all errors during regular expression execution,
which nullifies much of the benefit of having a dedicated exception
class in the first place.

It also violates the exception policy in

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

which states:

If an extension uses external functionality that may throw an exception
it MUST wrap any exception thrown by that functionality into an appropriate
exception of its own. It MUST set the $previous property to the original
exception when doing so.

On your second point, if this is a violation of a policy, then there isn't
much to argue. I will just retract the vote and fix that.

But I think I got confused here, and I would appreciate you explaining how
that violates the policy.

To make sure we're on the same ground, this is what I understood from your
statement about wrapping exceptions thrown in user callbacks:

preg_replace_callback(
    $pattern,
    fn () => throw new CustomException(), // <- You want this wrapped in
PregException?
    $subject,
    flags: PREG_THROW_ON_ERROR,
);

If I got it right (and I suspect I did), then how does that violate the
policy?
A user callback isn't external functionality, is it? Because as far as I
understand, external functionality is something the extension itself
depends on as part of its own implementation.

I am also unaware of any functions that behave like that (wraps exceptions
thrown in user callbacks in its own exception).

In fact, the opposite is the case for one of the precedents this RFC
follows (json_encode() with JSON_THROW_ON_ERROR - although it doesn't
accept a user callback): https://3v4l.org/CtHYH#v8.5.10

Thanks,
Osama

[RFC] [Discussion] array_str_contains() for PHP 8.7

Fri, 04 Sep 2026 18:57:18 +0000

Thanks for the reminder! I will add the RFC to the overview page shortly.

It appears this hasn't happened yet.

Best regards
Tim Düsterhus

[RFC] Scan results for array_str_contains

Fri, 04 Sep 2026 18:16:51 +0000

‪On Fri, 4 Sept 2026 at 19:03, ‫سپهر محمودی‬‎ sepehrphpr@gmail.com wrote:‬

در تاریخ جمعه ۴ سپتامبر ۲۰۲۶، ۲۱:۱۳ David CARLIER devnexen@gmail.com نوشت:

Hi,

‪On Thu, 3 Sept 2026 at 17:21, ‫سپهر محمودی‬‎ sepehrphpr@gmail.com wrote:‬

Hey internals,

Just wanted to follow up with the real-world data I promised for array_str_contains().

I scanned the top 200 Composer packages (around 21,000 PHP files) to see how people currently handle array substring searches. Here is what I found (32 matches total):

array_filter with str_contains: 8

array_filter with strpos: 8

array_filter with stripos: 6

foreach with str_contains: 6

array_filter with preg_match: 4

All these different (and sometimes verbose) approaches can simply be replaced with a single, clean, and fast native call:
array_str_contains($haystack, $needle)

I’ve updated the RFC with these findings:
https://wiki.php.net/rfc/array_str_contains

If you want to check out the script or raw JSON results, I uploaded them here:
https://gist.github.com/sepehrphpr/d4d371ba682cc43c4f258de94684cc91

Let me know what you think!

Cheers,
Sepehr

quick look in the RFC about this

"Non-string values in the array are implicitly cast to strings before
the check".

Is actually the case implementation wise ?

Hi David,

Yes, non-string scalar values (like integers or floats) can be cast/treated as strings during the search (similar to how some string-matching functions handle scalar inputs), or skipped if not convertible.

I will make sure the wording in the RFC clearly explains how non-string values within the array are handled.

Best regards,
Sepehr

you probably need to update your test to demonstrate it.

[RFC] Scan results for array_str_contains

Fri, 04 Sep 2026 18:02:51 +0000

در تاریخ جمعه ۴ سپتامبر ۲۰۲۶، ۲۱:۱۳ David CARLIER devnexen@gmail.com نوشت:

Hi,

‪On Thu, 3 Sept 2026 at 17:21, ‫سپهر محمودی‬‎ sepehrphpr@gmail.com
wrote:‬

Hey internals,

Just wanted to follow up with the real-world data I promised for
array_str_contains().

I scanned the top 200 Composer packages (around 21,000 PHP files) to see
how people currently handle array substring searches. Here is what I found
(32 matches total):

array_filter with str_contains: 8

array_filter with strpos: 8

array_filter with stripos: 6

foreach with str_contains: 6

array_filter with preg_match: 4

All these different (and sometimes verbose) approaches can simply be
replaced with a single, clean, and fast native call:
array_str_contains($haystack, $needle)

I’ve updated the RFC with these findings:
https://wiki.php.net/rfc/array_str_contains

If you want to check out the script or raw JSON results, I uploaded them
here:
https://gist.github.com/sepehrphpr/d4d371ba682cc43c4f258de94684cc91

Let me know what you think!

Cheers,
Sepehr

quick look in the RFC about this

"Non-string values in the array are implicitly cast to strings before
the check".

Is actually the case implementation wise ?

Hi David,

Yes, non-string scalar values (like integers or floats) can be cast/treated
as strings during the search (similar to how some string-matching functions
handle scalar inputs), or skipped if not convertible.

I will make sure the wording in the RFC clearly explains how non-string
values within the array are handled.

Best regards,
Sepehr