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