On Sun, 30 Aug 2026 at 23:20, سپهر محمودی <[email protected]> wrote: > > > > در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۰۰:۵۸ Seifeddine Gmati > <[email protected]> نوشت: >> >> On Sun, 30 Aug 2026 at 15:19, سپهر محمودی <[email protected]> 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.
