{"id":248,"date":"2026-05-18T13:00:44","date_gmt":"2026-05-18T13:00:44","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/php-8-4-array-find-and-friends-helpers-i-stopped-writing\/"},"modified":"2026-05-18T13:00:44","modified_gmt":"2026-05-18T13:00:44","slug":"php-8-4-array-find-and-friends-helpers-i-stopped-writing","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/php-8-4-array-find-and-friends-helpers-i-stopped-writing\/","title":{"rendered":"PHP 8.4 array_find and Friends: Helpers I Stopped Writing Myself"},"content":{"rendered":"

Confession: I wrote the same eight-line array_filter<\/code> plus current<\/code> pattern for almost ten years before PHP 8.4 finally shipped array_find<\/code>. A decade of current(array_filter($items, fn(...) => ...))<\/code> and squinting at it the next month wondering what it actually returned when nothing matched.<\/p>\n

If you’ve been writing PHP since 7.x, you know the pattern. You need the first item in a list that matches some condition. The language gave you tools that didn’t quite fit, so you stitched them together. Then PHP 8.4 dropped array_find<\/code>, array_find_key<\/code>, array_any<\/code>, and array_all<\/code>, and a family of helpers I’d been hand-rolling for years became one line each.<\/p>\n

I’m going to walk through what each one actually does, where I use them in production, and the one place where the old foreach<\/code> is still cleaner. The PHP 8.4 release page<\/a> is the canonical reference for the version overall.<\/p>\n

What array_find actually returns<\/h2>\n

The signature looks innocent:<\/p>\n

array_find(array $array, callable $callback): mixed\n<\/code><\/pre>\n
It returns the first value where the callback returns truthy, or null<\/code> if nothing matches. That null<\/code> is the part I want to flag, because it’s the part that tripped me up.<\/p>\n
Old PHP code I deleted last month:<\/p>\n
$user = current(array_filter($users, fn($u) => $u->email === $email));\nif ($user === false) {\n    return null;\n}\n<\/code><\/pre>\n
array_filter<\/code> returns an array with original keys preserved. current<\/code> on that array gives you the first element or false<\/code> on an empty array. So you have to check for false<\/code>, even though your data type is User<\/code>, and you have to know that current<\/code> is positioned wherever the filter started. Reading this six months later, the === false<\/code> looks like a bug, not a feature.<\/p>\n
The PHP 8.4 version:<\/p>\n
$user = array_find($users, fn($u) => $u->email === $email);\nif ($user === null) {\n    return null;\n}\n<\/code><\/pre>\n
Three changes that matter. The return type is mixed<\/code> not array|false<\/code>. Null is unambiguous, so the static analyzer doesn’t have to think about whether false<\/code> could be a valid value in your data. And there’s no intermediate filtered array allocated, which matters if your list is large.<\/p>\n
array_any and array_all: the predicates I used to write inline<\/h2>\n
These are the boolean cousins. array_any<\/code> returns true if at least one item matches the callback. array_all<\/code> returns true only if every item matches.<\/p>\n
Before PHP 8.4:<\/p>\n
$hasAdmin = !empty(array_filter($users, fn($u) => $u->role === 'admin'));\n$allVerified = count(array_filter($users, fn($u) => $u->verified))\n    === count($users);\n<\/code><\/pre>\n
Both work. Both allocate a temporary array I don’t care about, and the array_all<\/code> version walks the whole list even when the first failure is enough to answer the question.<\/p>\n
After:<\/p>\n
$hasAdmin = array_any($users, fn($u) => $u->role === 'admin');\n$allVerified = array_all($users, fn($u) => $u->verified);\n<\/code><\/pre>\n
The functions short-circuit. array_any<\/code> stops at the first match. array_all<\/code> stops at the first failure. On a list of ten thousand items where the first one fails the predicate, that’s a real speedup. On a list of three items, it’s a wash and you pick array_all<\/code> because it reads better.<\/p>\n
These are equivalent to JavaScript’s Array.prototype.some<\/code> and Array.prototype.every<\/code>, which I’d been wishing for in PHP for years.<\/p>\n
One small footgun: if your callback throws, array_any<\/code> and array_all<\/code> propagate the exception. That’s the right behavior, but I’ve seen people write predicates that call into network code or hit the database, then act surprised when one bad row blows up the whole check. Keep the predicates pure. If you need to do anything that can fail, do it in a separate pass and feed the result in.<\/p>\n
array_find_key: when I care about position<\/h2>\n
array_find<\/code> gives you the value. array_find_key<\/code> gives you the key. Sometimes I want the key because I’m about to write back into the array, or because the keys are meaningful (think a Record<orderId, Order><\/code> shape).<\/p>\n
$items = [\n    'order-1001' => new Order(...),\n    'order-1002' => new Order(...),\n    'order-1003' => new Order(...),\n];\n\n$failedKey = array_find_key($items, fn($o) => $o->status === 'failed');\n\nif ($failedKey !== null) {\n    unset($items[$failedKey]);\n}\n<\/code><\/pre>\n
The old version of this would be array_search<\/code> combined with a custom predicate, which array_search<\/code> doesn’t actually support. So you’d write a foreach<\/code> with a manual break. The new version is one line and the type signature carries through.<\/p>\n
There’s a quirk worth knowing. If your keys can legitimately be 0<\/code>, null<\/code>, or ''<\/code>, the “not found” sentinel of null<\/code> collides with a real key. You’ll want a strict comparison and probably a manual array_key_exists<\/code> check if you’re paranoid. The PHP manual entry for array_find_key<\/a> covers the edge cases.<\/p>\n
Where these still don’t help (and what to reach for)<\/h2>\n
I want to push back on the framing that these functions replace foreach<\/code>. They don’t. They replace array_filter<\/code> plus current<\/code> and similar three-step chains. For anything more complex than a single predicate, a foreach<\/code> is still cleaner.<\/p>\n
A real example. I needed to find the first failed order in a list, but also collect every order processed before it, because the audit log needed both. With array_find<\/code> I’d need two passes, one to find the index and one to slice. With foreach<\/code> it’s one pass:<\/p>\n
$processedBefore = [];\n$targetOrder = null;\nforeach ($orders as $order) {\n    if ($order->status === 'failed') {\n        $targetOrder = $order;\n        break;\n    }\n    $processedBefore[] = $order;\n}\n<\/code><\/pre>\n
This is the kind of mixed-state iteration that doesn’t fit into a single predicate. Using array_find<\/code> here would force me to either accept two passes or stop using these helpers entirely halfway through the function. The foreach<\/code> is honest about what it’s doing.<\/p>\n
Other places I still reach for the old patterns. When I need an index and a value together, I’ll often use array_map<\/code> with array_keys<\/code> even though it allocates, because the resulting code reads more like a transformation than a search. When the predicate is complex enough to deserve a named function, array_filter<\/code> with a named callback can be clearer than a long arrow function passed to array_find<\/code>.<\/p>\n
There’s also the case where I’m working with a Generator<\/code> rather than a plain array. None of the new helpers accept iterables. If you’ve been writing memory-efficient pipelines with yield<\/code>, you still need to handle the search yourself or convert to an array first, which defeats the purpose. I keep hoping a future PHP release adds iter_find<\/code> and friends. Until then, foreach<\/code> over a generator is the cleanest answer.<\/p>\n
I also still write small classes that wrap collection logic when the operations get hairy. My take on this is in the property hooks post I wrote a couple of months back<\/a>, where the same “let me delete some boilerplate” argument applies to a different language feature.<\/p>\n
What to try this week<\/h2>\n
Open your codebase. Search for array_filter<\/code> calls followed by current<\/code> or reset<\/code>. Every one of those is a candidate for array_find<\/code>. Then search for !empty(array_filter<\/code> and count(array_filter<\/code> and similar shapes. Those are array_any<\/code> and array_all<\/code> respectively.<\/p>\n
You’ll probably find more than you expect. I found 23 in our backend monorepo on the first sweep, and a few more once I started looking at the longer functions. Pick the ones where the type narrowing helps your static analyzer. Psalm and PHPStan both understand these new helpers, so you’ll get tighter inference for free.<\/p>\n
PHP 8.4 has been out for over a year at this point, so unless you’re stuck on an older version, there’s no reason not to lean on these. If your job involves the boring middle of a PHP codebase, my work on long-running PHP projects<\/a> covers more of this kind of refactor. The cumulative effect of a couple hundred small simplifications like these is real.<\/p>\n","protected":false},"excerpt":{"rendered":"
PHP 8.4 array_find, array_any, array_all, and array_find_key replaced years of array_filter plus current chains in my codebase. Here is what stuck.<\/p>\n","protected":false},"author":2,"featured_media":247,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"PHP 8.4 array_find, array_any, array_all, and array_find_key replaced years of array_filter plus current chains in my codebase. Here is what stuck.","rank_math_focus_keyword":"php 8.4","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[45],"tags":[49,53,287,50],"class_list":["post-248","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","tag-backend","tag-php","tag-php-8-4-2","tag-programming"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/248","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=248"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/248\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/247"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=248"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=248"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=248"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}