[RFC] [Discussion] array_str_contains() for PHP 8.7 View as Markdown

در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۰۲:۲۸ Seifeddine Gmati
azjezz@carthage.software نوشت:

‪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.

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

در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۱۶:۳۲ Bruce Weirdan weirdan@gmail.com نوشت:

Hi سپهر

‪On Mon, Aug 31, 2026 at 12:21 AM ‫سپهر محمودی‬‎ sepehrphpr@gmail.com
wrote:‬

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.

If this overhead could be reduced, it would improve the performance of any
built-in function that calls a user-land closure, not limited to the
array_filter + str_contains combo. Have you considered solving this problem
instead, at least for closures generated by partial applications of
built-in functions?

--
Best regards,
Bruce Weirdan mailto:
weirdan@gmail.com

Hi Bruce,

Thanks for the reply.

You're right that the closure invocation overhead is not specific to
array_filter + str_contains — it applies to any builtin that calls a
userland callable. However, I see these as complementary rather than
mutually exclusive approaches.

Optimizing closure invocation for partial applications is a deep change
in the engine (VM loop, call frames, possibly JIT/inline caching), and
would only benefit closures created from first-class callable syntax.
Even then, the userland code would remain more verbose, and the engine
would still have to materialize a call frame per element.

A dedicated function avoids the call overhead entirely with a few lines
of straightforward C, keeps userland code short and readable, and is
shippable now rather than being tied to a long-term engine project.

That said, I'd be genuinely interested in seeing a proposal for
optimizing first-class callable invocation — I think it would benefit
array_map/array_filter users broadly. But I don't think it should block
a small, pragmatic stdlib addition.

Best regards,
Sepehr