[PHP-DEV] [RFC] [Discussion] array_match

Mailing Lists php.internals
1

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

2

‪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:
PHP: 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:

- In past RFC in str_icontains PHP: 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
- youkidearitai (tekimen) · GitHub
-----------------------------

3

در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۶:۰۵ 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.

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

Regards
Yuya

–

Yuya Hamada (tekimen)

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.

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

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

4

‪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:
> PHP: 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:
Code search results · GitHub
- In past RFC in str_icontains PHP: 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
- youkidearitai (tekimen) · GitHub
-----------------------------

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:
> Code search results · GitHub

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
> PHP: 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
- youkidearitai (tekimen) · GitHub
-----------------------------

5

You can find all the use cases and examples detailed on the RFC page:
PHP: 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.

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.

6

در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۸:۱۴ 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.

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

Regards
Yuya

–

Yuya Hamada (tekimen)

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.

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

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)

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

7

در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۹:۱۰ 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.
array_filter($values, static fn($value) => str_contains($value, 'foo'));

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

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

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

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

8

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):
PHP: 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

در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۲:۴۰ 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

10

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.

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

11

Hi

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

I have updated the RFC to reflect these changes (Version 0.3):
PHP: 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

12

در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۷:۵۸ 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

13

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

14

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.

15

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:

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.

16

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

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

17

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