PHP RFC: array_get and array_has functions
- Version: 0.3
- Date: 2026-04-04
- Author: Carlos Granados, barel.barelon@gmail.com
- Status: Under discussion
- Implementation: https://github.com/php/php-src/pull/21637
Introduction
In PHP applications, it is very common to work with deeply nested arrays, especially when dealing with configuration data, decoded JSON payloads, request data, framework metadata, or other dynamic structures.
The use of “dot notation” to access these nested data structures is already widespread across PHP ecosystems and beyond. It is commonly used in frameworks, in configuration systems, and in many userland helper libraries. Outside of PHP, similar patterns appear in JavaScript when working with object paths, in JSON query tools, and in configuration formats where hierarchical data is represented as strings. Developers are therefore already familiar with expressing nested access using paths such as db.connections.mysql.host or users.0.email, and frequently implement their own helpers to support this pattern in PHP.
When the structure of the array is known in advance and the exact element to retrieve is hardcoded, existing PHP syntax works well:
<?php $array = ['products' => ['desk' => ['price' => 100]]]; $price = $array['products']['desk']['price'] ?? null;
However, this becomes much harder when the structure is dynamic and the key is also dynamic, for example because it is built at runtime, comes from configuration, or is derived from user input.
<?php $path = $_GET['field'] ?? 'products.desk.price'; // accessing $array using $path requires manual traversal today
In such cases, direct array access requires manual parsing of the key, iterative traversal of the array, repeated is_array() checks, and careful handling of missing intermediate segments.
This RFC proposes adding two small, focused array functions to ext/standard for accessing nested arrays using a path in a single step:
array_get()retrieves a value from a deeply nested array and returns a default value if the path does not exist.
array_has()checks whether a given nested path exists in an array.
These operations already appear across PHP codebases and frameworks whenever developers need to traverse structured array data dynamically. Standardizing them in core would make intent explicit, reduce repeated boilerplate, and provide consistent behaviour for edge cases.
Typical use cases include: reading dynamic configuration paths, traversing decoded JSON structures, accessing request payloads, resolving runtime-defined property paths, checking whether nested optional data exists before processing it, and working with framework or library metadata stored in arrays.
Proposal
This RFC proposes adding two small, focused array functions to ext/standard for accessing nested arrays using a path, in a single step. The path may be provided either as a dot-notation string such as db.connections.mysql.host or as an array path such as ['db', 'connections', 'mysql', 'host']:
Today, this is typically implemented via manual traversal, often by exploding a string path or iterating over an array path and looping through the array while checking whether each segment exists. This results in repeated boilerplate, inconsistent edge-case handling, and less intention-revealing code.
This proposal standardizes the behaviour in the core, making intent explicit (“get nested value”, “check nested path”), and enabling a fast and consistent implementation in C.
Why this brings substantial value: deeply nested array access is very common in modern PHP applications, especially when data is dynamic rather than statically known. These helpers provide:
- Readability / intent: “what” is expressed directly, not reconstructed from loops and nested checks.
- Consistency: everyone gets the same semantics for missing paths, null values, numeric keys, and non-array intermediate values.
- Less error-prone code: avoids repeated manual traversal logic and subtle differences between implementations.
- Convenience for dynamic access: especially useful when the path is built at runtime instead of written literally in code.
Features and examples
1) Retrieve nested values with a default fallback
Use case examples
- Read configuration values using dynamic keys
- Access JSON fields selected at runtime
- Resolve user-provided paths
<?php $field = $_GET['field'] ?? 'products.desk.price'; $value = array_get($array, $field, 'not found'); $path = ['products', 'desk', 'price']; $value2 = array_get($array, $path, 'not found');
Passing ['products', 'desk', 'price'] is equivalent to passing 'products.desk.price'.
2) Check whether a nested path exists
Use case examples
- Validate dynamic input paths
- Check optional configuration values
<?php $field = $_GET['field'] ?? 'product.name'; if (array_has($array, $field)) { // field was provided } $property = $_GET['property'] ?? 'name'; $path = ['product', $property]; if (array_has($array, $path)) { // property was provided }
Desired syntax and semantics
Function list (global namespace)
As proposed, the function signatures are:
array_get(array $array, array|string|int|null $key, mixed $default = null): mixed array_has(array $array, array|string|int $key): bool
Parameter order aims to follow existing conventions in related PHP functionality:
- The array being inspected is the first argument
- The key/path is the second argument
array_get()accepts an optional default value as the third argument
Common behaviour
String paths (dot notation): string keys are split on . into path segments, which are used to traverse the array one level at a time.
Array paths: if $key is an array, each element of the array is treated as one path segment.
Equivalent paths: passing ['home', 'sub', 'third'] is equivalent to passing 'home.sub.third'.
Allowed path segment types: when $key is an array, all path segments must be strings or integers. If any segment is of another type, traversal fails and the path is treated as not found.
Numeric path segments:
* if a segment is a numeric string such as “0”, it is treated as the integer key 0.
* In array paths, integer elements are used directly as integer keys.
Intermediate values must be arrays: if traversal reaches a value that is not an array before the path is fully consumed, traversal fails.
Missing path behaviour: If any path is not found, no errors or warnings will be thrown. Instead:
array_get()returns$defaultarray_has()returnsfalse
array_get() special case for null key:
- If
$keyisnull, the full input array is returned unchanged.
array_has() uses existence semantics similar to array_key_exists():
- If the final key exists and its value is
null,array_has()still returnstrue.
Exact semantics (per function)
array_get()
function array_get(array $array, array|string|int|null $key, mixed $default = null): mixed { if ($key === null) { return $array; } if (is_int($key)) { return array_key_exists($key, $array) ? $array[$key] : $default; } if (is_string($key)) { $segments = explode('.', $key); } else { $segments = $key; } foreach ($segments as $segment) { if (!is_string($segment) && !is_int($segment)) { return $default; } if (!is_array($array) || !array_key_exists($segment, $array)) { return $default; } $array = $array[$segment]; } return $array; }
- If
$keyis null: return the whole array unchanged. - If
$keyis an integer: check that key directly in the top-level array. - If
$keyis a string: split it on dots and traverse the array segment by segment. - If
$keyis an array: use its elements as path segments. - If any segment is not a string or integer: return
$default. - If any segment does not exist: return
$default. - If any intermediate value is not an array before traversal is complete: return
$default. - If the final key exists return its value.
array_has()
function array_has(array $array, array|string|int $key): bool { if (is_int($key)) { return array_key_exists($key, $array); } if (is_string($key)) { $segments = explode('.', $key); } else { $segments = $key; } foreach ($segments as $segment) { if (!is_string($segment) && !is_int($segment)) { return false; } if (!is_array($array) || !array_key_exists($segment, $array)) { return false; } $array = $array[$segment]; } return true; }
- If
$keyis an integer: check that key directly in the top-level array. - If
$keyis a string: split it on dots and traverse the array segment by segment. - If
$keyis an array: use its elements as path segments. - If any segment is not a string or integer: return
false. - If any segment does not exist: return
false. - If any intermediate value is not an array before traversal is complete: return
false. - If the final key exists return
true.
Edge cases and potential gotchas
nullkey inarray_get()
array_get(['a' => 1], null); // ['a' => 1]
This is useful in code paths where the caller may optionally provide a path and wants the original array returned unchanged when no path is given.
- Integer keys
array_get(['a', 'b'], 1); // 'b' array_has(['a', 'b'], 2); // false
If an integer key is used we retrieve or check that key directly in the top-level array.
- Numeric string path segments
$array = ['users' => [['name' => 'Alice']]]; array_get($array, 'users.0.name'); // 'Alice' array_has($array, 'users.0.name'); // true
Numeric string segments are interpreted as integer keys so that indexed arrays can be traversed naturally.
nullvalues
$array = ['a' => ['b' => null]]; array_get($array, 'a.b'); // null array_has($array, 'a.b'); // true
This matches existence semantics rather than isset() semantics.
- Literal dots in array keys
$array = ['user.name' => 'Carlos']; array_get($array, 'user.name'); // looks for ['user']['name'], not ['user.name']
This RFC does not propose an escaping mechanism for literal dots inside key names. Dot notation is interpreted structurally. If your path segments can include dots, pass an array of segments instead of a string.
- Invalid array path segments
$array = ['home' => ['sub' => ['third' => 'value']]]; array_get($array, ['home', new stdClass(), 'third'], 'default'); // 'default' array_has($array, ['home', new stdClass(), 'third']); // false
If an array path contains any segment that is neither a string nor an integer, the path is treated as not found.
Examples
- Simple get value examples:
$array = ['products' => ['desk' => ['price' => 100]]]; $price = array_get($array, 'products.desk.price'); // 100 $price = array_get($array, ['products', 'desk', 'price']); // 100 $discount = array_get($array, 'products.desk.discount', 0); // 0 $discount = array_get($array, ['products', 'desk', 'discount'], 0); // 0
- Existence checks:
$array = ['product' => ['name' => 'Desk', 'price' => 100]]; array_has($array, 'product.name'); // true array_has($array, ['product', 'name']); // true array_has($array, 'product.color'); // false array_has($array, ['product', 'color']); // false
- Indexed arrays:
$array = [ 'users' => [ ['name' => 'Alice'], ['name' => 'Bob'], ], ]; array_get($array, 'users.1.name'); // 'Bob' array_get($array, ['users', 1, 'name']); // 'Bob' array_has($array, 'users.2.name'); // false array_has($array, ['users', 2, 'name']); // false
- Dynamic example:
$path = $_GET['field'] ?? 'products.desk.price'; $value = array_get($array, $path, 'not found');
This last example illustrates one of the main motivations for this RFC: when the path is dynamic, direct array syntax is no longer practical, and the alternative is repeated userland traversal logic.
Backward Incompatible Changes
This proposal introduces two new global functions. It does not modify the behaviour of any existing functions, classes, language constructs, or extensions.
As with any new global function, there is a theoretical risk of name collisions with user-defined functions of the same name. However, a search in GitHub revealed only four public PHP repositories using these function names.
Proposed PHP Version(s)
PHP 8.6
RFC Impact
To the Ecosystem
The impact on the ecosystem is limited to tooling updates to recognize the newly introduced functions; no changes in behaviour, syntax, or analysis rules are required.
To Existing Extensions
None
To SAPIs
None
Open Issues
None at the moment
Future Scope
Possible future extensions, intentionally excluded from this RFC:
- Wildcard support such as products.*.price
- Equivalent helpers for objects or array/object mixed traversal
Voting Choices
Primary Vote requiring a 2/3 majority to accept the RFC:
Patches and Tests
Current implementation: https://github.com/php/php-src/pull/21637
Implementation
TODO: After acceptance.
References
The Laravel framework provides similar functionality through its Arr::get() and Arr::has() helper methods, which allow accessing and checking nested array values using dot notation. These helpers are widely used within the Laravel ecosystem and demonstrate the practical utility of this pattern in real-world PHP applications. Their widespread adoption indicates that developers frequently require a concise and consistent way to traverse nested arrays dynamically.
Similar functionality exists outside of PHP, particularly in the JavaScript ecosystem. The Lodash library provides get() and has() functions that support accessing nested object properties using string paths. Its docs explicitly state that path can be either Array|string, with examples using both string paths and array paths. These functions are widely used in JavaScript applications to safely traverse complex data structures. The presence of equivalent utilities in other languages and ecosystems further highlights that this is a common and well-understood pattern rather than a framework-specific abstraction.
Discussion: https://news-web.php.net/php.internals/130559
Changelog
- 2026-04-04: Initial RFC published
- 2026-04-04: Discussion started on internals
- 2026-04-05: Add references to implementations in userland and other languages
- 2026-04-05: Add open issues for string lists as keys and dot escaping
- 2026-04-06: Modify the proposal so that the $key parameter can also be a list of strings/ints