Re: [RFC] [Discussion] array_match

‪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����.ԛ�� > �5J��4 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 -----------------------------