در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۲:۴۰ Christian Schneider < [email protected]> نوشت:
> Am 22.08.2026 um 22:31 schrieb سپهر محمودی <[email protected]>: > > 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
