Re: [RFC] [Discussion] array_match

> Do you think the performance gain for such a common use-case justifies having a dedicated > function, or do you feel the language should strictly prefer the > array_filter approach despite the overhead? > I don't mean to dismiss Tim's response, especially since you asked him and his response comes from a lot more experience: I don't think performance alone is a good reason to introduce a new narrower function. I have worked on Drupal, WordPress, Silex, and bespoke code bases, spending enough time profiling them. An array string search has never been a bottleneck. The PHP project itself also has benchmarks of common PHP applications. If a meaningful number of these common use cases can receive a performance improvement, then I think we can consider a dedicated function. PHP 8.5, for example, has Engine optimizations when comparing a value against an empty array ( === [] and !== []). These are really meaningful improvements that do not necessarily change the API surface. Newer functions like str_contains, str_ends_with, array_find, etc had a strong argument in favor of them, that they improve the ergonomics of the language. With the PFA syntax like Tim mentioned (and contributed!), I would pick the PFA approach any day of the week: ```php array_filter($values, str_contains(?, 'foo')); ``` I'm truly thankful that you're spending time to improve PHP, and I really don't mean to sound discouraging from this email. I just think that that is still a room in PHP for Engine optimizations and bottle necks that PHP could use your expertise. A new array_str_contains function might not get the same approval and agreement and, that, might in fact, discourage you. Thank you, Ayesh.