Re: [RFC] [Discussion] array_str_contains() for PHP 8.7

From: Date: Sun, 30 Aug 2026 22:57:58 +0000
Subject: Re: [RFC] [Discussion] array_str_contains() for PHP 8.7
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-132393@lists.php.net to get a copy of this message
‪On Sun, 30 Aug 2026 at 23:20, ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com> wrote:‬ > > > > در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۰۰:۵۸ Seifeddine Gmati > <azjezz@carthage.software> نوشت: >> >> On Sun, 30 Aug 2026 at 15:19, ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com> >> wrote:‬ >> > >> > Hi everyone, >> > >> > I'd like to start the discussion for a new RFC proposing the >> > array_str_contains() function for PHP 8.7. >> >> Hi Sepehr, >> >> > Filtering arrays based on substring matching is something many of us write on a >> > regular basis, usually with boilerplate like: >> > $matches = array_filter($array, fn($item) => is_string($item) && >> > str_contains($item, $needle)); >> >> I don't recall ever writing something like this. If I did, not >> remembering it suggests it isn't that common. >> >> The RFC also does not include any proof of the "regular basis", and >> under same conditions, the same case could be made for >> array_str_starts_with, array_str_ends_with, array_preg_match, >> array_str_length, and probably few more hunder combinations, I really >> don't see how str_contains is in any way special. >> >> The name array_str_contains is also confusing, it does not >> tell me >> what this function is doing, there is nothing indicating that it is >> filtering. array_str_contains($arr, $str) could mean that >> every >> string is joined with $str so by the end all string entries >> in >> $arr do contain $str? Idk. >> >> > Thanks, >> > Sepehr >> >> Cheers, >> Seifeddine. > > > -------- > Hi Seifeddine, > > Thank you for your feedback and perspective! Hi again. > > Regarding the use-case and frequency: > Sub-string filtering on lists of strings is a very common task across many domains — such as > autocomplete suggestions, filtering file/directory lists, simple search filters over tag/category > arrays, and processing logs or URL lists. Do you have any numbers to support this? Did you run an analysis on open-source projects? > While array_filter with a closure can achieve this, it > introduces noticeable overhead in userland due to repeated closure invocations and type checks on > every element. Implementing this natively in C provides direct memory traversal and immediate > performance gains for a very frequent real-world operation. This can be said about any existing function that takes a callable, and any other callable, e.g., array_map + str_rot13. Or again, any other 2 functions fitting the description. I still don't see why the combination of array_filter + str_contains is special. > Regarding other variants (starts_with, > ends_with, etc.): > str_contains is arguably the most general and widely-used > substring operation. However, discussing whether a broader set of string-array utilities or a more > specific naming convention makes sense is exactly why this RFC is in discussion. I wasn't advocating for adding more to this RFC; I'm saying that this function is redundant. It makes no sense to have it as part of the stdlib. > Best regards, > Sepehr Cheers.

« previous php.internals (#132393) next »