Everything

php

Home » Project » Newsgroups » php.internals » [RFC] [Discussion] array_match »

[RFC] [Discussion] array_match

php.internals

سپهر محمودی

10 days ago

Hi everyone,

As some of you may know, my previous RFC (`array_search_range`) faced
significant opposition and feedback. I have listened to the community and
officially withdrawn it. Thank you to everyone who took the time to review
it.

Today, I would like to introduce a new, much simpler, and highly focused
RFC: `array_match()`

Currently, if we want to filter an array to find elements containing a
specific substring, we have to rely on `array_filter()` combined with a
closure and `strpos()`/`stripos()`. This pattern is not only verbose but
also carries the performance overhead of executing a PHP closure for every
single array element.

I am proposing a native function to handle this efficiently in C:
`array_match(array $array, string $needle, bool $ignore_case = false):
array`

This function preserves the original keys, safely casts values to strings,
and provides a clean, intent-revealing syntax. By implementing this
internally, we can significantly improve both readability and execution
speed compared to userland polyfills.

You can find all the use cases and examples detailed on the RFC page:
https://wiki.php.net/rfc/array_match

I look forward to hearing your thoughts and feedback on this proposal!

Best regards,
Sepehr Mahmoudi

youkidearitai

10 days ago

‪2026年8月22日(土) 21:02 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬

>
> Hi everyone,
>
> As some of you may know, my previous RFC (`array_search_range`) faced significant opposition and feedback. I have listened to the community and officially withdrawn it. Thank you to everyone who took the time to review it.
>
> Today, I would like to introduce a new, much simpler, and highly focused RFC: `array_match()`
>
> Currently, if we want to filter an array to find elements containing a specific substring, we have to rely on `array_filter()` combined with a closure and `strpos()`/`stripos()`. This pattern is not only verbose but also carries the performance overhead of executing a PHP closure for every single array element.
>
> I am proposing a native function to handle this efficiently in C:
> `array_match(array $array, string $needle, bool $ignore_case = false): array`
>
> This function preserves the original keys, safely casts values to strings, and provides a clean, intent-revealing syntax. By implementing this internally, we can significantly improve both readability and execution speed compared to userland polyfills.
>
> You can find all the use cases and examples detailed on the RFC page:
> https://wiki.php.net/rfc/array_match
>
> I look forward to hearing your thoughts and feedback on this proposal!
>
> Best regards,
> Sepehr Mahmoudi
>

Hi, Sepehr.

I have some questions.

- Why need this function? Is not enough in array_filter or array_find?
-  In GitHub, There are many use cases in same name functions. from:
https://github.com/search?q=array_match+language%3APHP&type=code
- In past RFC in str_icontains https://wiki.php.net/rfc/str_icontains
was declind. So I don't think make sense that "case-insensitive" only
ASCII now.

For your reference: In big OSS like php-src, We investigate use case first.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------

سپهر محمودی

10 days ago

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

> ‪2026年8月22日(土) 21:02 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬
> >
> > Hi everyone,
> >
> > As some of you may know, my previous RFC (`array_search_range`) faced
> significant opposition and feedback. I have listened to the community and
> officially withdrawn it. Thank you to everyone who took the time to review
> it.
> >
> > Today, I would like to introduce a new, much simpler, and highly focused
> RFC: `array_match()`
> >
> > Currently, if we want to filter an array to find elements containing a
> specific substring, we have to rely on `array_filter()` combined with a
> closure and `strpos()`/`stripos()`. This pattern is not only verbose but
> also carries the performance overhead of executing a PHP closure for every
> single array element.
> >
> > I am proposing a native function to handle this efficiently in C:
> > `array_match(array $array, string $needle, bool $ignore_case = false):
> array`
> >
> > This function preserves the original keys, safely casts values to
> strings, and provides a clean, intent-revealing syntax. By implementing
> this internally, we can significantly improve both readability and
> execution speed compared to userland polyfills.
> >
> > You can find all the use cases and examples detailed on the RFC page:
> > https://wiki.php.net/rfc/array_match
> >
> > I look forward to hearing your thoughts and feedback on this proposal!
> >
> > Best regards,
> > Sepehr Mahmoudi
> >
>
> Hi, Sepehr.
>
> I have some questions.
>
> - Why need this function? Is not enough in array_filter or array_find?
> -  In GitHub, There are many use cases in same name functions. from:
> https://github.com/search?q=array_match+language%3APHP&type=code
> - In past RFC in str_icontains https://wiki.php.net/rfc/str_icontains
> was declind. So I don't think make sense that "case-insensitive" only
> ASCII now.
>
> For your reference: In big OSS like php-src, We investigate use case first.
>
> Regards
> Yuya
>
> --
> ---------------------------
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -----------------------------
>

Hi Yuya,

Thank you for taking the time to review the RFC and share your thoughts!

> - Why need this function? Is not enough in array_filter or array_find?

While `array_filter()` is great, it requires a Closure for this task. For
large arrays, the overhead of calling a userland function for every single
element is significant. `array_match()` aims to provide a fast, native C
alternative for a very common operation.
As for `array_find()` (introduced in PHP 8.4), it only returns the *first*
matching element, whereas this proposal filters and returns *all* matching
elements.

> - In GitHub, There are many use cases in same name functions. from:
> https://github.com/search?q=array_match+language%3APHP&type=code

I think the high number of custom `array_match` implementations in userland
actually proves how much developers need this functionality! However, you
bring up a valid point regarding potential name collisions (BC breaks). If
`array_match` conflicts with too many existing codebases, I am completely
open to bikeshedding the name (perhaps `array_str_contains()` or something
similar).

> - In past RFC in str_icontains
> https://wiki.php.net/rfc/str_icontains
> was declind. So I don't think make sense that "case-insensitive" only
> ASCII now.

This is a very solid point. If the `$ignore_case` parameter brings up the
same ASCII/Unicode complexities that caused `str_icontains` to be declined,
I am more than happy to drop the `$ignore_case` parameter entirely. A
simple, fast, case-sensitive filter would still be highly valuable.

> For your reference: In big OSS like php-src, We investigate use case

first.

Understood! I have included a few use cases (like log filtering, simple
search, and performance optimization over Closures) in the RFC. The GitHub
search link you provided is also a great testament to real-world usage.

Thanks again for your feedback, it is very helpful.

Best regards,
Sepehr

youkidearitai

10 days ago

‪2026年8月22日(土) 22:31 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬

>
>
>
> در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۶:۰۵ youkidearitai <youkidearitai@gmail.com> نوشت:
>>
>> ‪2026年8月22日(土) 21:02 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬
>> >
>> > Hi everyone,
>> >
>> > As some of you may know, my previous RFC (`array_search_range`) faced significant opposition and feedback. I have listened to the community and officially withdrawn it. Thank you to everyone who took the time to review it.
>> >
>> > Today, I would like to introduce a new, much simpler, and highly focused RFC: `array_match()`
>> >
>> > Currently, if we want to filter an array to find elements containing a specific substring, we have to rely on `array_filter()` combined with a closure and `strpos()`/`stripos()`. This pattern is not only verbose but also carries the performance overhead of executing a PHP closure for every single array element.
>> >
>> > I am proposing a native function to handle this efficiently in C:
>> > `array_match(array $array, string $needle, bool $ignore_case = false): array`
>> >
>> > This function preserves the original keys, safely casts values to strings, and provides a clean, intent-revealing syntax. By implementing this internally, we can significantly improve both readability and execution speed compared to userland polyfills.
>> >
>> > You can find all the use cases and examples detailed on the RFC page:
>> > https://wiki.php.net/rfc/array_match
>> >
>> > I look forward to hearing your thoughts and feedback on this proposal!
>> >
>> > Best regards,
>> > Sepehr Mahmoudi
>> >
>>
>> Hi, Sepehr.
>>
>> I have some questions.
>>
>> - Why need this function? Is not enough in array_filter or array_find?
>> -  In GitHub, There are many use cases in same name functions. from:
>> https://github.com/search?q=array_match+language%3APHP&type=code
>> - In past RFC in str_icontains https://wiki.php.net/rfc/str_icontains
>> was declind. So I don't think make sense that "case-insensitive" only
>> ASCII now.
>>
>> For your reference: In big OSS like php-src, We investigate use case first.
>>
>> Regards
>> Yuya
>>
>> --
>> ---------------------------
>> Yuya Hamada (tekimen)
>> - https://tekitoh-memdhoi.info
>> - https://github.com/youkidearitai
>> -----------------------------
>
>
> Hi Yuya,
>
> Thank you for taking the time to review the RFC and share your thoughts!
>
> > - Why need this function? Is not enough in array_filter or array_find?
>
> While `array_filter()` is great, it requires a Closure for this task. For large arrays, the overhead of calling a userland function for every single element is significant. `array_match()` aims to provide a fast, native C alternative for a very common operation.
> As for `array_find()` (introduced in PHP 8.4), it only returns the *first* matching element, whereas this proposal filters and returns *all* matching elements.
>
> > - In GitHub, There are many use cases in same name functions. from:
> > https://github.com/search?q=array_match+language%3APHP&type=code
>
> I think the high number of custom `array_match` implementations in userland actually proves how much developers need this functionality! However, you bring up a valid point regarding potential name collisions (BC breaks). If `array_match` conflicts with too many existing codebases, I am completely open to bikeshedding the name (perhaps `array_str_contains()` or something similar).
>
> > - In past RFC in str_icontains
> > https://wiki.php.net/rfc/str_icontains
> > was declind. So I don't think make sense that "case-insensitive" only
> > ASCII now.
>
> This is a very solid point. If the `$ignore_case` parameter brings up the same ASCII/Unicode complexities that caused `str_icontains` to be declined, I am more than happy to drop the `$ignore_case` parameter entirely. A simple, fast, case-sensitive filter would still be highly valuable.
>
> > For your reference: In big OSS like php-src, We investigate use case first.
>
> Understood! I have included a few use cases (like log filtering, simple search, and performance optimization over Closures) in the RFC. The GitHub search link you provided is also a great testament to real-world usage.
>
> Thanks again for your feedback, it is very helpful.
>
> Best regards,
> Sepehr
>

Hi

> I think the high number of custom `array_match` implementations in userland actually proves how much developers need this functionality

No, Could you read carefully userland code of `array_match` functions?
`array_match` is seems a lot of use case in implementation, One of
`array_match` is uses regex in first parameter,
But other implementation of `array_match` is not same behavior.
You should read usecases of userland code.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------

سپهر محمودی

9 days ago

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

> ‪2026年8月22日(土) 22:31 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬
> >
> >
> >
> > در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۶:۰۵ youkidearitai <youkidearitai@gmail.com>
> نوشت:
> >>
> >> ‪2026年8月22日(土) 21:02 ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com>:‬
> >> >
> >> > Hi everyone,
> >> >
> >> > As some of you may know, my previous RFC (`array_search_range`) faced
> significant opposition and feedback. I have listened to the community and
> officially withdrawn it. Thank you to everyone who took the time to review
> it.
> >> >
> >> > Today, I would like to introduce a new, much simpler, and highly
> focused RFC: `array_match()`
> >> >
> >> > Currently, if we want to filter an array to find elements containing
> a specific substring, we have to rely on `array_filter()` combined with a
> closure and `strpos()`/`stripos()`. This pattern is not only verbose but
> also carries the performance overhead of executing a PHP closure for every
> single array element.
> >> >
> >> > I am proposing a native function to handle this efficiently in C:
> >> > `array_match(array $array, string $needle, bool $ignore_case =
> false): array`
> >> >
> >> > This function preserves the original keys, safely casts values to
> strings, and provides a clean, intent-revealing syntax. By implementing
> this internally, we can significantly improve both readability and
> execution speed compared to userland polyfills.
> >> >
> >> > You can find all the use cases and examples detailed on the RFC page:
> >> > https://wiki.php.net/rfc/array_match
> >> >
> >> > I look forward to hearing your thoughts and feedback on this proposal!
> >> >
> >> > Best regards,
> >> > Sepehr Mahmoudi
> >> >
> >>
> >> Hi, Sepehr.
> >>
> >> I have some questions.
> >>
> >> - Why need this function? Is not enough in array_filter or array_find?
> >> -  In GitHub, There are many use cases in same name functions. from:
> >> https://github.com/search?q=array_match+language%3APHP&type=code
> >> - In past RFC in str_icontains https://wiki.php.net/rfc/str_icontains
> >> was declind. So I don't think make sense that "case-insensitive" only
> >> ASCII now.
> >>
> >> For your reference: In big OSS like php-src, We investigate use case
> first.
> >>
> >> Regards
> >> Yuya
> >>
> >> --
> >> ---------------------------
> >> Yuya Hamada (tekimen)
> >> - https://tekitoh-memdhoi.info
> >> - https://github.com/youkidearitai
> >> -----------------------------
> >
> >
> > Hi Yuya,
> >
> > Thank you for taking the time to review the RFC and share your thoughts!
> >
> > > - Why need this function? Is not enough in array_filter or array_find?
> >
> > While `array_filter()` is great, it requires a Closure for this task.
> For large arrays, the overhead of calling a userland function for every
> single element is significant. `array_match()` aims to provide a fast,
> native C alternative for a very common operation.
> > As for `array_find()` (introduced in PHP 8.4), it only returns the
> *first* matching element, whereas this proposal filters and returns *all*
> matching elements.
> >
> > > - In GitHub, There are many use cases in same name functions. from:
> > > https://github.com/search?q=array_match+language%3APHP&type=code
> >
> > I think the high number of custom `array_match` implementations in
> userland actually proves how much developers need this functionality!
> However, you bring up a valid point regarding potential name collisions (BC
> breaks). If `array_match` conflicts with too many existing codebases, I am
> completely open to bikeshedding the name (perhaps `array_str_contains()` or
> something similar).
> >
> > > - In past RFC in str_icontains
> > > https://wiki.php.net/rfc/str_icontains
> > > was declind. So I don't think make sense that "case-insensitive" only
> > > ASCII now.
> >
> > This is a very solid point. If the `$ignore_case` parameter brings up
> the same ASCII/Unicode complexities that caused `str_icontains` to be
> declined, I am more than happy to drop the `$ignore_case` parameter
> entirely. A simple, fast, case-sensitive filter would still be highly
> valuable.
> >
> > > For your reference: In big OSS like php-src, We investigate use case
> first.
> >
> > Understood! I have included a few use cases (like log filtering, simple
> search, and performance optimization over Closures) in the RFC. The GitHub
> search link you provided is also a great testament to real-world usage.
> >
> > Thanks again for your feedback, it is very helpful.
> >
> > Best regards,
> > Sepehr
> >
>
> Hi
>
> > I think the high number of custom `array_match` implementations in
> userland actually proves how much developers need this functionality
>
> No, Could you read carefully userland code of `array_match` functions?
> `array_match` is seems a lot of use case in implementation, One of
> `array_match` is uses regex in first parameter,
> But other implementation of `array_match` is not same behavior.
> You should read usecases of userland code.
>
> Regards
> Yuya
>
> --
> ---------------------------
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -----------------------------
>

Hi Yuya,

Thank you for the valuable feedback and for taking the time to look into
the userland implementations.

I completely agree with your point about the name `array_match`. Since
"match" is often associated with regex (like `preg_match`) or can imply
different behaviors in userland, it could be misleading. To make the
function's purpose absolutely clear and consistent with existing PHP
functions, I have renamed the proposal to `array_str_contains`.

Additionally, I have entirely removed the 3rd parameter (`$ignore_case`).
You made a great point regarding the ASCII/Unicode complexities, and
considering the history with the rejected `str_icontains` RFC, it makes
sense to drop it and keep the behavior strictly aligned with
`str_contains()`.

I have updated the RFC to reflect these changes (Version 0.3):
https://wiki.php.net/rfc/array_str_contains

Let me know if you have any further thoughts on this updated version.

Best regards,
Sepehr

Christian Schneider

9 days ago

Am 22.08.2026 um 22:31 schrieb ⁨سپهر محمودی⁩ <⁨sepehrphpr@gmail.com⁩>:

> Additionally, I have entirely removed the 3rd parameter (`$ignore_case`). You made a great point regarding the ASCII/Unicode complexities, and considering the history with the rejected `str_icontains` RFC, it makes sense to drop it and keep the behavior strictly aligned with `str_contains()`.
>
> I have updated the RFC to reflect these changes (Version 0.3):
> https://wiki.php.net/rfc/array_str_contains

Why not use preg_grep which basically does the same thing (and would support both case insensitivity and Unicode)?

Sure, you need a delimiter and if you have special characters in your $needle then you need to use preg_quote but for all your examples but your function basically boils down to
function array_str_contains($haystack, $needle) { return preg_grep('/' . preg_quote($needle, '/') . '/', $haystack); }

I don't think it is worth adding this to the already quite large list of array_-functions.

Regards,
- Chris

سپهر محمودی

9 days ago

در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۲:۴۰ Christian Schneider <
cschneid@cschneid.com> نوشت:

> Am 22.08.2026 um 22:31 schrieb ⁨سپهر محمودی⁩ <⁨sepehrphpr@gmail.com⁩>:
> > Additionally, I have entirely removed the 3rd parameter
> (`$ignore_case`). You made a great point regarding the ASCII/Unicode
> complexities, and considering the history with the rejected `str_icontains`
> RFC, it makes sense to drop it and keep the behavior strictly aligned with
> `str_contains()`.
> >
> > I have updated the RFC to reflect these changes (Version 0.3):
> > https://wiki.php.net/rfc/array_str_contains
>
> Why not use preg_grep which basically does the same thing (and would
> support both case insensitivity and Unicode)?
>
> Sure, you need a delimiter and if you have special characters in your
> $needle then you need to use preg_quote but for all your examples but your
> function basically boils down to
> function array_str_contains($haystack, $needle) { return preg_grep('/' .
> preg_quote($needle, '/') . '/', $haystack); }
>
> I don't think it is worth adding this to the already quite large list of
> array_-functions.
>
> Regards,
> - Chris
>

------
Hi Chris,

Thanks for your feedback and for raising these valid points. I understand
the hesitation about adding yet another function to the `array_*` family,
but I'd like to share my perspective on why this addition is valuable,
especially compared to existing alternatives like `preg_grep()`.

While `preg_grep()` is a powerful tool, it is fundamentally designed for
regular expressions. Using it for a simple substring search requires adding
delimiters and wrapping the needle in `preg_quote()` to prevent syntax
errors if the string contains special characters. This introduces
unnecessary boilerplate and regex engine overhead for what should be a
straightforward operation.

The core motivation behind `array_str_contains()` comes down to Ergonomics
(DX) and Performance:

1. Ergonomics: Just as `str_contains()` was introduced to replace the
verbose `strpos() !== false`, `array_str_contains()` is meant to eliminate
boilerplate for arrays. It provides a clean, highly readable, and
expressive way to perform a very common everyday task. It is much more
developer-friendly than writing an `array_filter()` with a closure or a
safely escaped `preg_grep()`.

2. Performance: A dedicated native C implementation bypasses the overhead
of userland closure calls (which `array_filter` relies on) and the regex
compilation/execution steps (which `preg_grep` requires). For larger
arrays, this offers a clean performance win.

I believe that providing a simple, native function for this specific and
frequent use case brings enough practical value to everyday PHP development
to justify its inclusion.

Best regards,
Sepehr

Tim Düsterhus

9 days ago

Hi

On 8/22/26 21:31, سپهر محمودی wrote:

> I have updated the RFC to reflect these changes (Version 0.3):
> https://wiki.php.net/rfc/array_str_contains

Please keep reusing the same Wiki page for the same RFC and do not
create a new one when updating the RFC. It is confusing when the link in
the email of the discussion thread is going to an outdated version of
the RFC and it also effectively breaks the version history of the Wiki,
which makes it hard to see what changed in the RFC.

Basically creating a new Wiki page is equivalent to creating a new RFC
entirely and that means it also needs to have a separate discussion
thread according to policy.

Best regards
Tim Düsterhus

سپهر محمودی

9 days ago

در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۷:۵۸ Tim Düsterhus <tim@bastelstu.be> نوشت:

> Hi
>
> On 8/22/26 21:31, سپهر محمودی wrote:
> > I have updated the RFC to reflect these changes (Version 0.3):
> > https://wiki.php.net/rfc/array_str_contains
>
> Please keep reusing the same Wiki page for the same RFC and do not
> create a new one when updating the RFC. It is confusing when the link in
> the email of the discussion thread is going to an outdated version of
> the RFC and it also effectively breaks the version history of the Wiki,
> which makes it hard to see what changed in the RFC.
>
> Basically creating a new Wiki page is equivalent to creating a new RFC
> entirely and that means it also needs to have a separate discussion
> thread according to policy.
>
> Best regards
> Tim Düsterhus
>

-------


Hi Tim,

You're absolutely right. The new syntax in PHP 8.6 makes using
`array_filter` incredibly clean and elegant, and I completely agree on the
readability aspect.

However, my main motivation for this RFC is performance. When dealing with
large arrays, the overhead of executing a callback (even a built-in one)
for every single element in `array_filter` can be quite significant. A
dedicated function implemented purely in C would bypass that overhead and
execute much faster.

Do you think the performance gain for such a common use-case justifies
having a dedicated function, or do you feel the language should strictly
prefer the `array_filter` approach despite the overhead?

Best regards,
Sepehr

Christian Schneider

9 days ago

Am 23.08.2026 um 17:50 schrieb ⁨سپهر محمودی⁩ <⁨sepehrphpr@gmail.com⁩>:

> However, my main motivation for this RFC is performance. When dealing with large arrays, the overhead of executing a callback (even a built-in one) for every single element in `array_filter` can be quite significant. A dedicated function implemented purely in C would bypass that overhead and execute much faster.

Maybe you want to back this up with some benchmarks of real world cases you had to deal with.

Personally, we are dealing with large files and in our experience the bottle neck is more often memory than speed. This means we often use a streaming approach for large data sets to avoid having the whole data in memory. Which wouldn't work well with your proposed function and the performance impact would probably negligible.

> Do you think the performance gain for such a common use-case justifies having a dedicated function, or do you feel the language should strictly prefer the `array_filter` approach despite the overhead?

I think the performance of array_filter is good enough for 99% of the cases, preg_grep (which in most cases will be simple enough if the search string is a fixed string) is good enough for 99% of the remaining performance critical cases which dissuades me from adding another function for the remaining 0.01%.

Regards,
- Chris

Ayesh - PHP.Watch

9 days ago

> Do you think the performance gain for such a common use-case justifies having a dedicated function, or do you feel the language should strictly prefer the `array_filter` approach despite the overhead?
>

I don't mean to dismiss Tim's response, especially since you asked him
and his response comes from a lot more experience: I don't think
performance alone is a good reason to introduce a new narrower
function.

I have worked on Drupal, WordPress, Silex, and bespoke code bases,
spending enough time profiling them. An array string search has never
been a bottleneck.

The PHP project itself also has benchmarks of common PHP applications.
If a meaningful number of these common use cases can receive a
performance improvement, then I think we can consider a dedicated
function.

PHP 8.5, for example, has Engine optimizations when comparing a value
against an empty array ( `=== []` and `!== []`). These are really
meaningful improvements that do not necessarily change the API
surface.

Newer functions like `str_contains`, `str_ends_with`, `array_find`,
etc had a strong argument in favor of them, that they improve the
ergonomics of the language. With the PFA syntax like Tim mentioned
(and contributed!), I would pick the PFA approach any day of the week:

```php
array_filter($values, str_contains(?, 'foo'));
```

I'm truly thankful that you're spending time to improve PHP,  and I
really don't mean to sound discouraging from this email. I just think
that that is still a room in PHP for Engine optimizations and bottle
necks that PHP could use your expertise. A new `array_str_contains`
function might not get the same approval and agreement and, that,
might in fact, discourage you.

Thank you,
Ayesh.

Larry Garfield

9 days ago

On Sun, Aug 23, 2026, at 10:45 AM, Ayesh Karunaratne wrote:

> Newer functions like `str_contains`, `str_ends_with`, `array_find`,
> etc had a strong argument in favor of them, that they improve the
> ergonomics of the language. With the PFA syntax like Tim mentioned
> (and contributed!), I would pick the PFA approach any day of the week:

Fact check: PFA was written by Arnaud Le Blanc, designed by myself along with Joe Watkins, Levi Morrison, and a few others back in 2021.  Tim was an active reviewer to the RFC but did not author it.  (He has authored other successful and valuable RFCs.)

> ```php
> array_filter($values, str_contains(?, 'foo'));
> ```
>
> I'm truly thankful that you're spending time to improve PHP,  and I
> really don't mean to sound discouraging from this email. I just think
> that that is still a room in PHP for Engine optimizations and bottle
> necks that PHP could use your expertise. A new `array_str_contains`
> function might not get the same approval and agreement and, that,
> might in fact, discourage you.

I think there's an XY problem going on here.  Sephr, you seem based on your RFC proposals to be very concerned about the performance of massively huge arrays.  As others have noted, in general massively huge arrays in memory is a code smell, and indicates that you should be using a different approach to begin with.  (It could be doing more work in SQL, or streaming data from a file using generators, or various other things.)  Perhaps you can describe your actual use case better, and we can point you at a more effective solution that doesn't require custom C functions.

If it really does involve custom C functions, then you're definitely into territory where writing a small custom extension for your project specifically is a worthwhile thing to do, and then you wouldn't need to go through the RFC process at all.

--Larry Garfield

mickmackusa

8 days ago

I just want to add a few points to the discussion.

With an increasing number of software developers offloading code writing to
AI, there's probably a decreasing weight to which "ergonomics" can be
argued. Don't get me wrong, I love concise and elegant code, but not for
_code golfing_ reasons and there are diminishing returns in such adventures.

As for performance arguments, we need to see real benchmarks versus related
processes returning the same result to understand the amount of performance
gains. We may also need to understand if there are thresholds where the
performance differences are more/less noticeable.

This proposal is coupling one iterating function with one string function.
Think about the precedent adopting this proposal would set. Would the
language slip into bloating its array function family with tens of other
combinations _for performance/ergonomic reasons_?

I am not in favor of the array_match() or array_str_contains() proposals,
but an alternative not surfaced in this thread is the idea of polymorphism
with the already existent str_contains() function. In other words, make it
behave like str_replace() whether a haystack parameter is a string or an
array of strings. I don't know if the language is trying to avoid such a
convention, but I know I've personally wished that `preg_quote()` could
directly receive an array of strings before imploding its result with pipes
(and I've seen countless php-regex posts on Stack Overflow of array_map()
making preg_quote() calls before imploding).

While it is completely natural to muse language modifications based on our
own encounters with development, before devoting time to a proposal, sense
check that the change would significantly improve the language and benefit
a significant number of developers and codebases.  Maybe take time to
silently draft 3 to 5 distinctly different proposals, then critically
compare and rank them from most to least compelling for general developers,
then deliver your best proposal. Such an exercise will help you to
self-evaluate which proposal(s) are ready to share with the internals
mailing list, which ones need more consideration, and which ones might
never become compelling proposals.

Sincerely,
mickmackusa

Ayesh - PHP.Watch

9 days ago

> Please keep reusing the same Wiki page for the same RFC and do not
> create a new one when updating the RFC. It is confusing when the link in
> the email of the discussion thread is going to an outdated version of
> the RFC and it also effectively breaks the version history of the Wiki,
> which makes it hard to see what changed in the RFC.
>
> Basically creating a new Wiki page is equivalent to creating a new RFC
> entirely and that means it also needs to have a separate discussion
> thread according to policy.
>

Thank you so much for mentioning this point too.
I'm "watching" the RFC pages on Dokuwiki, and I thought I had Déjà vu
because the new RFC text made no mention of the just-renamed RFC while
losing all the discussions behind it.

Ayesh - PHP.Watch

10 days ago

> You can find all the use cases and examples detailed on the RFC page:
> https://wiki.php.net/rfc/array_match
>
> I look forward to hearing your thoughts and feedback on this proposal!

I'm thumbs down on this for a few reasons.

1. We already have `str_contains` function. It is more intuitive that
a false `strpos` call, and it makes an `array_filter` function clean
too.

```php
array_filter($values, static fn($value) => str_contains($value, 'foo'));
```

2. I think this is a quite narrow use case. Even the RFC text example
is arguably a poor use case for a `str_contains` check. When checking
file extensions, it should be a str-ends-with check rather than a
str-contains check.

3. Echoing what Yuya mentioned, the case sensitivity is quite
difficult to reach a consensus on, for the same reasons why
`str_icontains` RFC was declined. At this stage, I argue we should not
add case-insensitive switches to any new functions.

4. Functions like this tend to be incomplete; someone else might argue
for preserving array keys or filtering by array keys. We already have
`array_filter` that can do all of it in any way the caller wants.

5. Finally, and somewhat opinionatedly, the word "match" resonates
more with regular expressions. `preg_match` in PHP itself,
`String.match()` in JS, `re.match()` in Python, etc to name a few.

Thank you.
Ayesh.

سپهر محمودی

9 days ago

در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۹:۱۰ Ayesh Karunaratne <ayesh@php.watch> نوشت:

> > You can find all the use cases and examples detailed on the RFC page:
> > https://wiki.php.net/rfc/array_match
> >
> > I look forward to hearing your thoughts and feedback on this proposal!
>
>
> I'm thumbs down on this for a few reasons.
>
> 1. We already have `str_contains` function. It is more intuitive that
> a false `strpos` call, and it makes an `array_filter` function clean
> too.
>
> ```php
> array_filter($values, static fn($value) => str_contains($value, 'foo'));
> ```
>
> 2. I think this is a quite narrow use case. Even the RFC text example
> is arguably a poor use case for a `str_contains` check. When checking
> file extensions, it should be a str-ends-with check rather than a
> str-contains check.
>
> 3. Echoing what Yuya mentioned, the case sensitivity is quite
> difficult to reach a consensus on, for the same reasons why
> `str_icontains` RFC was declined. At this stage, I argue we should not
> add case-insensitive switches to any new functions.
>
> 4. Functions like this tend to be incomplete; someone else might argue
> for preserving array keys or filtering by array keys. We already have
> `array_filter` that can do all of it in any way the caller wants.
>
> 5. Finally, and somewhat opinionatedly, the word "match" resonates
> more with regular expressions. `preg_match` in PHP itself,
> `String.match()` in JS, `re.match()` in Python, etc to name a few.
>
> Thank you.
> Ayesh.
>

------‐-‐---

Hi Ayesh,

Thank you so much for your constructive feedback. I really appreciate the
points you raised!

Based on your suggestions and the feedback from the list, I have made
several major updates to the RFC. First, to avoid any confusion with
regular expressions, I have renamed the proposal and the function to
array_str_contains. I also removed the third parameter to keep the behavior
strictly aligned with the exact matching of str_contains(), and explicitly
stated that original array keys are preserved.

Regarding your valid point about using array_filter(), I have added a new
subsection under *“Use Cases”* specifically addressing *“Why a native
function instead of array_filter?”*. It highlights the ergonomics and the
performance benefits of avoiding closure overhead and context switching in
C. I also replaced the file extension example with a more practical URL
filtering scenario, as you suggested.

I would be grateful if you could take a look at the updated “Use Cases”
section. You can find the relocated and updated RFC page here:

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

Thanks again for your time and for helping me improve this proposal.

Best regards,

Sepehr

Tim Düsterhus

9 days ago

Hi

On 8/22/26 17:40, Ayesh Karunaratne wrote:

> I'm thumbs down on this for a few reasons.
>
> 1. We already have `str_contains` function. It is more intuitive that
> a false `strpos` call, and it makes an `array_filter` function clean
> too.
>
> ```php
> array_filter($values, static fn($value) => str_contains($value, 'foo'));
> ```

With PHP 8.6 this could even just be:

array_filter($values, str_contains(?, 'foo'));

Other than that, I agree with your email entirely.

Best regards
Tim Düsterhus