Re: [RFC] [Discussion] array_match

From: Date: Sun, 23 Aug 2026 11:12:42 +0000
Subject: Re: [RFC] [Discussion] array_match
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-132299@lists.php.net to get a copy of this message
در تاریخ یکشنبه ۲۳ اوت ۲۰۲۶، ۱۲:۴۰ 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: 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

« previous php.internals (#132299) next »