Re: [RFC] [Discussion] array_match

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