PHP's proposed array_str_contains() would let you filter an array by a substring in one call. Pass it a list of URLs and 'products', for example, and get back only the URLs containing that text, with their original keys intact.

Sepehr Mahmoudi's RFC targets PHP 8.7. and it's still under discussion, but if it passes then the filtering pattern becomes shorter to write.

The Old Way and the Proposed Way

As an example, say you have these URLs and want just the product pages:

$urls = [
    'https://example.com/products/laptops',
    'https://example.com/about-us',
    'https://example.com/products/phones',
    'https://example.com/contact',
];

Right now you can combine array_filter() with str_contains() to get the results:

$products = array_filter(
    $urls,
    fn($url) => str_contains($url, 'products')
);

With the proposed function, that becomes:

$products = array_str_contains($urls, 'products');

Both would give you the same result for this list of strings:

[
    0 => 'https://example.com/products/laptops',
    2 => 'https://example.com/products/phones',
]

The callback goes away, and the array and search text are the only arguments. The same call could pick out log lines containing 'ERROR:' or filenames containing 'invoice'.

The search is case-sensitive, so 'products' would not match 'Products'. It returns all matching entries and preserves their keys, just as array_filter() does. If your callback also checks other conditions, you'd still need to keep that logic.

Will It Make PHP 8.7?

As of September 8, the RFC is under discussion, no vote is open, and the implementation has not been merged. PHP 8.7 is the proposed target, not a confirmed release for the function.

The discussion so far suggests it faces an uphill vote. Several participants question whether saving a callback justifies another built-in function. Others have asked for stronger performance evidence or a name that makes the filtering behavior clearer.

The author's scan of 200 Composer packages found 32 related patterns, but manual review showed that at least 15 needed extra logic. That leaves up to 17 possible replacements, which has not settled the question of how widely useful the function would be.

You can follow the proposal and any future vote on the RFC page.