[RFC] [Discussion] array_match

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

3 weeks ago by youkidearitai — view source — reply

unread

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

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

3 weeks ago by youkidearitai — view source — reply

unread

‪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

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)

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

3 weeks ago by Christian Schneider — view source — reply

unread

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

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

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

3 weeks ago by tim@bastelstu.be — view source — reply

unread

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

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

Hi

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

3 weeks ago by Christian Schneider — view source — reply

unread

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

3 weeks ago by Ayesh Karunaratne — view source — reply

unread

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.

3 weeks ago by Larry Garfield — view source — reply

unread

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

3 weeks ago by mickmackusa — view source — reply

unread

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

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ mickmackusa mickmackusa@gmail.com نوشت:

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

Hi everyone,

Thank you all for the valuable feedback on the array_str_contain proposal
so far.

Based on the recent technical discussions, especially regarding Unicode
handling and performance (thanks Yuya for the insights), I am focusing the
design on a UTF-8 by default approach. This will ensure full and efficient
support for non-Latin characters and emojis, which aligns perfectly with
modern web standards.

I am currently refining the implementation and will update the RFC details
accordingly. In the meantime, if anyone has specific edge cases regarding
this UTF-8 approach that I should keep in mind during testing, I would be
happy to hear them.

Thanks again for your time and guidance.

Best regards,
Sepehr

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

Hi everyone,

Thank you all for the valuable feedback, especially regarding the
complexities of case-insensitive searches and locale dependencies.

Based on the discussions, I have updated the RFC and simplified the design
to avoid those issues. Here are the major changes:

The function is now strictly case-sensitive (byte-for-byte matching).
This ensures native support for UTF-8, non-Latin characters, and emojis
without the need for complex decoding.
The $ignore_case parameter has been removed. The signature is now
simply: array_str_contain(array $haystack, string $needle): array
The implementation target is moved to ext/standard, completely removing
the ICU dependency and improving performance.
The target version is set to PHP 8.6.

You can review the updated RFC here:
https://wiki.php.net/rfc/array_str_contants

I believe this simplified version covers the primary use cases while
eliminating the performance and localization bottlenecks we discussed.

I would appreciate any further thoughts on this updated design.

Best regards,
Sepehr

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۵۰ سپهر محمودی sepehrphpr@gmail.com نوشت:

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ mickmackusa mickmackusa@gmail.com
نوشت:

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

Hi everyone,

Thank you all for the valuable feedback on the array_str_contain
proposal so far.

Based on the recent technical discussions, especially regarding Unicode
handling and performance (thanks Yuya for the insights), I am focusing the
design on a UTF-8 by default approach. This will ensure full and efficient
support for non-Latin characters and emojis, which aligns perfectly with
modern web standards.

I am currently refining the implementation and will update the RFC details
accordingly. In the meantime, if anyone has specific edge cases regarding
this UTF-8 approach that I should keep in mind during testing, I would be
happy to hear them.

Thanks again for your time and guidance.

Best regards,
Sepehr

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

Hi everyone,

Apologies, there was a typo in the link I just sent.
Here is the correct link to the updated RFC:
https://wiki.php.net/rfc/array_str_contains

Thanks,
Sepehr

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۱۴:۵۸ سپهر محمودی sepehrphpr@gmail.com نوشت:

Hi everyone,

Thank you all for the valuable feedback, especially regarding the
complexities of case-insensitive searches and locale dependencies.

Based on the discussions, I have updated the RFC and simplified the design
to avoid those issues. Here are the major changes:

The function is now strictly case-sensitive (byte-for-byte matching).
This ensures native support for UTF-8, non-Latin characters, and emojis
without the need for complex decoding.

The $ignore_case parameter has been removed. The signature is now
simply: array_str_contain(array $haystack, string $needle): array

The implementation target is moved to ext/standard, completely removing
the ICU dependency and improving performance.

The target version is set to PHP 8.6.

You can review the updated RFC here:
https://wiki.php.net/rfc/array_str_contants

I believe this simplified version covers the primary use cases while
eliminating the performance and localization bottlenecks we discussed.

I would appreciate any further thoughts on this updated design.

Best regards,
Sepehr

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۵۰ سپهر محمودی sepehrphpr@gmail.com
نوشت:

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ mickmackusa mickmackusa@gmail.com
نوشت:

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

Hi everyone,

Thank you all for the valuable feedback on the array_str_contain
proposal so far.

Based on the recent technical discussions, especially regarding Unicode
handling and performance (thanks Yuya for the insights), I am focusing the
design on a UTF-8 by default approach. This will ensure full and efficient
support for non-Latin characters and emojis, which aligns perfectly with
modern web standards.

I am currently refining the implementation and will update the RFC
details accordingly. In the meantime, if anyone has specific edge cases
regarding this UTF-8 approach that I should keep in mind during testing, I
would be happy to hear them.

Thanks again for your time and guidance.

Best regards,
Sepehr

3 weeks ago by Larry Garfield — view source — reply

unread

Hi everyone,

Thank you all for the valuable feedback, especially regarding the
complexities of case-insensitive searches and locale dependencies.

Based on the discussions, I have updated the RFC and simplified the
design to avoid those issues. Here are the major changes:

The function is now strictly case-sensitive (byte-for-byte
matching). This ensures native support for UTF-8, non-Latin characters,
and emojis without the need for complex decoding.

The $ignore_case parameter has been removed. The signature is now
simply: array_str_contain(array $haystack, string $needle): array

The implementation target is moved to ext/standard, completely
removing the ICU dependency and improving performance.

The target version is set to PHP 8.6.

PHP 8.6 is feature-frozen and not accepting new RFCs. The earliest it could target is PHP 8.7.

You can review the updated RFC here:
https://wiki.php.net/rfc/array_str_contants

I believe this simplified version covers the primary use cases while
eliminating the performance and localization bottlenecks we discussed.

I would appreciate any further thoughts on this updated design.

Best regards,
Sepehr

Also, please remember to bottom post, not top post.

--Larry Garfield

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۱۸:۳۲ Larry Garfield larry@garfieldtech.com
نوشت:

Hi everyone,

Thank you all for the valuable feedback, especially regarding the
complexities of case-insensitive searches and locale dependencies.

Based on the discussions, I have updated the RFC and simplified the
design to avoid those issues. Here are the major changes:

The function is now strictly case-sensitive (byte-for-byte
matching). This ensures native support for UTF-8, non-Latin characters,
and emojis without the need for complex decoding.

The $ignore_case parameter has been removed. The signature is now
simply: array_str_contain(array $haystack, string $needle): array

The implementation target is moved to ext/standard, completely
removing the ICU dependency and improving performance.

The target version is set to PHP 8.6.

PHP 8.6 is feature-frozen and not accepting new RFCs. The earliest it
could target is PHP 8.7.

You can review the updated RFC here:
https://wiki.php.net/rfc/array_str_contants

I believe this simplified version covers the primary use cases while
eliminating the performance and localization bottlenecks we discussed.

I would appreciate any further thoughts on this updated design.

Best regards,
Sepehr

Also, please remember to bottom post, not top post.

--Larry Garfield

Hi Larry,

Thanks for the heads up. I have updated the RFC wiki page to target PHP
8.7.
Also, noted on the bottom-posting rule!

Best regards,
Sepehr

3 weeks ago by Ayesh Karunaratne — view source — reply

unread

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.

3 weeks ago by Ayesh Karunaratne — view source — reply

unread

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.

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'));

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

3 weeks ago by sepehrphpr@gmail.com — view source — reply

unread

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

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

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.

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.

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

3 weeks ago by tim@bastelstu.be — view source — reply

unread

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

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