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

در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۸:۱۴ youkidearitai <[email protected]>
نوشت:

> ‪2026年8月22日(土) 22:31 ‫سپهر محمودی‬‎ <[email protected]>:‬
> >
> >
> >
> > در تاریخ شنبه ۲۲ اوت ۲۰۲۶، ۱۶:۰۵ youkidearitai <[email protected]>
> نوشت:
> >>
> >> ‪2026年8月22日(土) 21:02 ‫سپهر محمودی‬‎ <[email protected]>:‬
> >> >
> >> > 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