Re: [RFC] [Discussion] array_str_contains() for PHP 8.7
| From: | Seifeddine Gmati | 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.