در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۰۲:۲۸ Seifeddine Gmati <[email protected]> نوشت:
> 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. > ----------- Hi Saif, Thanks for the follow-up and the tough questions. 1. Regarding data and open-source analysis: You make a valid point about backing this up with concrete data. During this 14-day discussion period, I will run static analysis across top Packagist/GitHub packages (looking for patterns matching array_filter with str_contains/stripos closures) and update the RFC with empirical frequency data. 2. Regarding composability vs dedicated helpers: Comparing fundamental substring filtering to niche combinations like `array_map` + `str_rot13` isn't entirely an apples-to-apples comparison. Substring matching across collections is a ubiquitous, everyday task in web development (handling URL routes, file path filtering, tagging systems, autocomplete candidate lists, etc.). PHP has historically added focused, highly-optimized standard functions where the pattern is so overwhelmingly common that saving closure allocations, call frame overhead, and boilerplate significantly improves DX and execution speed. 3. Redundancy and stdlib scope: I completely understand your stance regarding keeping the standard library lean and relying on userland composition. Finding the right balance between minimal stdlib and developer ergonomics is precisely what the discussion and voting phases are meant to evaluate. I appreciate your critical feedback—it helps refine the RFC and ensures we substantiate the proposal with concrete metrics before voting. Best regards, Sepehr
