# [RFC] [Discussion] array_get and array_has functions

- Thread: https://externals.io/message/130559
- Original archive: https://news-web.php.net/php.internals/130559
- Started by Barel on 2026-04-04T14:06:21+00:00
- Messages: 39
- RFC: array_path_get and array_path_exists functions (Declined) — https://externals.io/rfc/array_get_and_array_has.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/130559.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #130559 — Barel — 2026-04-04T14:06:21+00:00

URL: https://externals.io/message/130559#130559

Hi,

I would like to open the discussion on my proposal to add two small,
focused array functions for retrieving and checking nested array elements
using dot notation.

This is the link to the RFC:
https://wiki.php.net/rfc/array_get_and_array_has

This is the link to the proposed implementation:
https://github.com/php/php-src/pull/21637

Thanks!!

Carlos

---

## #130560 — Juris Evertovskis — 2026-04-04T16:04:08+00:00

URL: https://externals.io/message/130559#130560 · In reply to: #130559

From: Barel <barel.barelon@gmail.com> 
Sent: Saturday, April 4, 2026 5:06 PM
To: PHP internals <internals@lists.php.net>
Subject: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions

 

Hi,

 

I would like to open the discussion on my proposal to add two small, focused array functions for retrieving and checking nested array elements using dot notation.

This is the link to the RFC: https://wiki.php.net/rfc/array_get_and_array_has

This is the link to the proposed implementation: https://github.com/php/php-src/pull/21637

 

Thanks!!

 

Carlos

 

Hey,

 

Very useful functions!

 

Why did you decide to not handle keys with dots? It would prevent these functions from being used in tools that might sometimes receive something like `example.com`as the key. The similar userland functions that I’ve seen do at least support the exact dotted key as well, even if not offering a full dotted<->nested equivalence with priority rules, partial nested-dotted and other fun stuff.

 

I’ve also found it quite useful to have `[‘user.name’ => ‘Alice’]` be equivalent to `[‘user’ => [‘name’ => ‘Alice’]]` for testing/mocking more complex structures.

 

BR,

Juris

---

## #130561 — drealecs@gmail.com — 2026-04-04T16:53:57+00:00

URL: https://externals.io/message/130559#130561 · In reply to: #130559

Hi Carlos,

This sounds interesting.

A mature solution used in JS is lodash, with the get and has functions:
- https://lodash.com/docs/#get
- https://lodash.com/docs/#has
Also, from what I could search, Laravel array helpers have this
functionality as well:
- https://laravel.com/docs/master/helpers#method-array-get
- https://laravel.com/docs/master/helpers#method-array-has
I was curious; did you research both, and maybe also other libraries? If
yes, it would be nice to mention this in the RFC.

They have some options, like allowing the key parameter as a list of
strings as well.
And also escaping the dot in the key in one way or another.

-- 
Alex




> Hi,
>
> I would like to open the discussion on my proposal to add two small,
> focused array functions for retrieving and checking nested array elements
> using dot notation.
>
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has
>
> This is the link to the proposed implementation:
> https://github.com/php/php-src/pull/21637
>
> Thanks!!
>
> Carlos

---

## #130562 — AllenJB — 2026-04-04T18:15:09+00:00

URL: https://externals.io/message/130559#130562 · In reply to: #130559

> Hi,
>
> I would like to open the discussion on my proposal to add two small, 
> focused array functions for retrieving and checking nested array 
> elements using dot notation.
>
> This is the link to the RFC: 
> https://wiki.php.net/rfc/array_get_and_array_has
>
> This is the link to the proposed implementation: 
> https://github.com/php/php-src/pull/21637
>
> Thanks!!
>
> Carlos

I echo others comments with regards to looking at / comparing to 
existing implementations (particularly Laravel, given its popularity), 
and escaping.

I would also suggest that the function names should explicitly indicate 
they use dot notation to reduce potential confusion over which array 
functions accept dot notation and avoid potential conflicts should 
similar non-dot-notation equivalents be desired (for these or any future 
dot-notation supporting array_ functions)

---

## #130564 — Aleksander Machniak — 2026-04-05T06:14:57+00:00

URL: https://externals.io/message/130559#130564 · In reply to: #130559

> This is the link to the RFC: https://wiki.php.net/rfc/ 
> array_get_and_array_has <https://wiki.php.net/rfc/array_get_and_array_has>
I'd prefer $key=null case removed. It's not that useful, not on pair 
with array_has(), and one would debate what to do with the $default in 
this case.

I'm not sure this needs to be stated in the RFC, but I hope they do not 
throw a warning when the key does not exist, on any level.

-- 
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

---

## #130565 — Rob Landers — 2026-04-05T06:51:30+00:00

URL: https://externals.io/message/130559#130565 · In reply to: #130559

> Hi,
> 
> I would like to open the discussion on my proposal to add two small, focused array functions for retrieving and checking nested array elements using dot notation.
> 
> This is the link to the RFC: https://wiki.php.net/rfc/array_get_and_array_has
> 
> This is the link to the proposed implementation: https://github.com/php/php-src/pull/21637
> 
> Thanks!!
> 
> Carlos

Hi Barel,

Interesting! As dot-notation isn't used anywhere else, and I don't see it discussed as part of the RFC, how are developers to prevent injections of dots in user input? With SQL, we have parameters and escaping ... but I don't see any of that here.

As an example:

$user = [ 'data' => [...], 'password' => 'secret' ];

If the path is completely user-controlled (as in the examples given), then they can access sensitive information in the array. Even if it is prefixed, ie., "data.%s" -- an attacker can simply enumerate all possible keys and subkeys.

As it stands, it appears to add a new vulnerability to PHP that will be unfamiliar with PHP developers -- unless they're using a framework that already does this sort of notation.

— Rob

---

## #130566 — Hans Krentel — 2026-04-05T08:13:44+00:00

URL: https://externals.io/message/130559#130566 · In reply to: #130559

> Hi,
> 
> I would like to open the discussion on my proposal to add two small,
> focused array functions for retrieving and checking nested array elements
> using dot notation.
> 
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has
> 
> This is the link to the proposed implementation:
> https://github.com/php/php-src/pull/21637
> 
> Thanks!!

Thank you very much! That’s very interesting, so I have to ask right away: Is there a specific reason to limit this to strings, integers, and null for arrays, rather than also allowing arrays or iterables?

This reminds me of JSON Pointers (RFC 6901), which can usually be easily mapped as an iterable with string keys, which can then be accessed via the holder variable, similar to the foreach example you already describe in your RFC.

If these two functions supported passing an array/iterable with the traversal keys as a second parameter, this would be advantageous, since the JSON pointer would then not need to be recoded into dot notation, but only (if not already done) sliced and passed as an array as the second parameter.

That's why I'm asking.

Interestingly, JSON Pointer solves the “null problem” by prefixing the zero or more reference tokens (keys) with a slash ‘/’, and it supports all seven types of JSON values without limiting itself to just JSON arrays or objects. This is just food for thought: array_... are clearly array functions, so this “restriction” is likely intentional. In PHP, however, I can also imagine iterables that resemble what you’ve already described in your RFC, and from there it’s not far to the holder object we see in JSON and JSON Pointer. So please don’t confuse my “request” regarding arrays/iterables with the first parameter; it’s simply about passing the key as a keys, which is a small improvement over dot notation.

With arrays in PHP, users will likely prefer the non-standard, more custom dot notation, and that’s perfectly fine. I saw many people asking for this in the early days of Stack Overflow, and if Symfony/Laravel have it as well, that’s just another strong indication of such a preference.

Thanks again for your RFC


--hakre

P.S. Work on the RFC documentation for JSON Path finally began in 2020, and it was published in February 2024. The standard has its roots in PHP and JavaScript, and perhaps it’s time for PHP to expand its standard library with such features at the same pace we did with JSON. Your RFC seems well-suited for this purpose. Thanks again.

---

## #130567 — Hans Krentel — 2026-04-05T08:22:18+00:00

URL: https://externals.io/message/130559#130567 · In reply to: #130565

> 
> > […]
> 
> Hi Barel,
> 
> Interesting! As dot-notation isn't used anywhere else, and I don't see it discussed as part of the RFC, how are developers to prevent injections of dots in user input? With SQL, we have parameters and escaping ... but I don't see any of that here.
> 
> As an example:
> 
> $user = [ 'data' => [...], 'password' => 'secret' ];
> 
> If the path is completely user-controlled (as in the examples given), then they can access sensitive information in the array. Even if it is prefixed, ie., "data.%s" -- an attacker can simply enumerate all possible keys and subkeys.
> 
> As it stands, it appears to add a new vulnerability to PHP that will be unfamiliar with PHP developers -- unless they're using a framework that already does this sort of notation.

I wouldn’t go that far, but I’d like to start by emphasizing that the dot notation described here clearly does not provide a mechanism for escaping the dot. That’s probably a shortcoming, but if any user-supplied string key poses a security risk, then PHP arrays are also affected, and this vulnerability would be nothing new! (Rather, it would be to be expected.)

-- hakre

---

## #130568 — Barel — 2026-04-05T09:07:05+00:00

URL: https://externals.io/message/130559#130568 · In reply to: #130561

On Sat, 4 Apr 2026 at 18:54, Alexandru Pătrănescu <drealecs@gmail.com>
wrote:

> Hi Carlos,
>
> This sounds interesting.
>
> A mature solution used in JS is lodash, with the get and has functions:
> - https://lodash.com/docs/#get
> - https://lodash.com/docs/#has
> Also, from what I could search, Laravel array helpers have this
> functionality as well:
> - https://laravel.com/docs/master/helpers#method-array-get
> - https://laravel.com/docs/master/helpers#method-array-has
> I was curious; did you research both, and maybe also other libraries? If
> yes, it would be nice to mention this in the RFC.
>
> They have some options, like allowing the key parameter as a list of
> strings as well.
> And also escaping the dot in the key in one way or another.
>
> --
> Alex
>

Hi Alex,

Thanks for your comments. I have updated the RFC with references to the
Laravel and Lodash implementations

Allowing the key parameter as a list of strings sounds really interesting,
let me explore that possibility

Several other people mentioned escaping dots as something important, so I
will look into adding that to the implementation

Cheers

Carlos


>
>
> 
>
> > […]

---

## #130569 — Rob Landers — 2026-04-05T09:12:02+00:00

URL: https://externals.io/message/130559#130569 · In reply to: #130567

> 
> 
> 
> 
> 
> 
> > […]
> 
> I wouldn’t go that far, but I’d like to start by emphasizing that the dot notation described here clearly does not provide a mechanism for escaping the dot. That’s probably a shortcoming, but if any user-supplied string key poses a security risk, then PHP arrays are also affected, and this vulnerability would be nothing new! (Rather, it would be to be expected.)
> 
> -- hakre
> 

My point is that this is different and distinct from regular array vulnerabilities and injections.

$user['data'][$key] !== array_get($user['data'], $key, null);

In the former 'some.key' is a full key; in the latter, it would access ['some']['key'].

Further, the former could be a valid key, but there is no way to access it using the proposed RFC

— Rob

---

## #130570 — Barel — 2026-04-05T09:19:22+00:00

URL: https://externals.io/message/130559#130570 · In reply to: #130562

> 
> > […]
>
> I echo others comments with regards to looking at / comparing to
> existing implementations (particularly Laravel, given its popularity),
> and escaping.
>
> I would also suggest that the function names should explicitly indicate
> they use dot notation to reduce potential confusion over which array
> functions accept dot notation and avoid potential conflicts should
> similar non-dot-notation equivalents be desired (for these or any future
> dot-notation supporting array_ functions)
>
>
Hi,

Thanks for your comments, I modified the RFC to include some references and
to look into escaping

Regarding function names, what would be your suggestion?

Cheers

Carlos

---

## #130571 — Barel — 2026-04-05T09:31:11+00:00

URL: https://externals.io/message/130559#130571 · In reply to: #130564

> 
> > […]
> https://wiki.php.net/rfc/array_get_and_array_has>
> I'd prefer $key=null case removed. It's not that useful, not on pair
> with array_has(), and one would debate what to do with the $default in
> this case.
>
> I'm not sure this needs to be stated in the RFC, but I hope they do not
> throw a warning when the key does not exist, on any level.
>

Thanks for your comments. I would like to hear what other people think
about the `null` case. I find it useful but if other people think it is
unnecessary, it can be easily removed. In any case, the $default would not
be used in this case

And, no, no warning will be thrown if any part of the path does not exist,
being able to easily support not existing paths is one of the main reasons
for this RFC

Cheers

Carlos



>
> --
> Aleksander Machniak
> Kolab Groupware Developer        [https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> ----------------------------------------------------
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

---

## #130572 — Barel — 2026-04-05T09:34:58+00:00

URL: https://externals.io/message/130559#130572 · In reply to: #130565

> 
>
> Hi,
>
> I would like to open the discussion on my proposal to add two small,
> focused array functions for retrieving and checking nested array elements
> using dot notation.
>
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has
>
> This is the link to the proposed implementation:
> https://github.com/php/php-src/pull/21637
>
> Thanks!!
>
> Carlos
>
>
> Hi Barel,
>
> Interesting! As dot-notation isn't used anywhere else, and I don't see it
> discussed as part of the RFC, how are developers to prevent injections of
> dots in user input? With SQL, we have parameters and escaping ... but I
> don't see any of that here.
>
> As an example:
>
> $user = [ 'data' => [...], 'password' => 'secret' ];
>
>
> If the path is completely user-controlled (as in the examples given), then
> they can access sensitive information in the array. Even if it is prefixed,
> ie., "data.%s" -- an attacker can simply enumerate all possible keys and
> subkeys.
>
> As it stands, it appears to add a new vulnerability to PHP that will be
> unfamiliar with PHP developers -- unless they're using a framework that
> already does this sort of notation.
>
> — Rob
>

Thanks Rob. Probably user input is not the best use case for these
functions, I just used it in the examples because it is simple. In any
case, if your program allows unrestricted array access using a user defined
path, the vulnerability already exists, these functions just make it easier
to implement the access. If you did not have them and wanted the same
functionality you would use a custom implementation (like the one provided
by Laravel) and you would have the same vulnerability

Cheers

Carlos

---

## #130573 — Barel — 2026-04-05T09:43:03+00:00

URL: https://externals.io/message/130559#130573 · In reply to: #130566

>
> 
>
> > […]
>
> Thank you very much! That’s very interesting, so I have to ask right away:
> Is there a specific reason to limit this to strings, integers, and null for
> arrays, rather than also allowing arrays or iterables?
>
> This reminds me of JSON Pointers (RFC 6901), which can usually be easily
> mapped as an iterable with string keys, which can then be accessed via the
> holder variable, similar to the foreach example you already describe in
> your RFC.
>
> If these two functions supported passing an array/iterable with the
> traversal keys as a second parameter, this would be advantageous, since the
> JSON pointer would then not need to be recoded into dot notation, but only
> (if not already done) sliced and passed as an array as the second parameter.
>
> That's why I'm asking.
>
> Interestingly, JSON Pointer solves the “null problem” by prefixing the
> zero or more reference tokens (keys) with a slash ‘/’, and it supports all
> seven types of JSON values without limiting itself to just JSON arrays or
> objects. This is just food for thought: array_... are clearly array
> functions, so this “restriction” is likely intentional. In PHP, however, I
> can also imagine iterables that resemble what you’ve already described in
> your RFC, and from there it’s not far to the holder object we see in JSON
> and JSON Pointer. So please don’t confuse my “request” regarding
> arrays/iterables with the first parameter; it’s simply about passing the
> key as a keys, which is a small improvement over dot notation.
>
> With arrays in PHP, users will likely prefer the non-standard, more custom
> dot notation, and that’s perfectly fine. I saw many people asking for this
> in the early days of Stack Overflow, and if Symfony/Laravel have it as
> well, that’s just another strong indication of such a preference.
>
> Thanks again for your RFC
>
>
> --hakre
>
> P.S. Work on the RFC documentation for JSON Path finally began in 2020,
> and it was published in February 2024. The standard has its roots in PHP
> and JavaScript, and perhaps it’s time for PHP to expand its standard
> library with such features at the same pace we did with JSON. Your RFC
> seems well-suited for this purpose. Thanks again.
>

Thanks for your comments. Someone else already suggested allowing arrays
for the $key parameter and I am considering it, I think it will probably be
a good addition

Cheers

Carlos

---

## #130574 — Hans Krentel — 2026-04-05T10:52:12+00:00

URL: https://externals.io/message/130559#130574 · In reply to: #130573

> 
> 
> > […]
> 
> Thanks for your comments. Someone else already suggested allowing arrays
> for the $key parameter and I am considering it, I think it will probably be
> a good addition

Yes, I agree, and I suggest we also consider _iterable_ as part of this discussion.

Thank you Carlos as well for your work on these functions.

--hakre

---

## #130575 — Rob Landers — 2026-04-05T11:10:59+00:00

URL: https://externals.io/message/130559#130575 · In reply to: #130572

> 
> > […]
> 
> Thanks Rob. Probably user input is not the best use case for these functions, I just used it in the examples because it is simple.

And quite dangerous. I’d recommend using realistic examples that showcase the work instead of simple examples that scream “hack me” to anyone who’s written PHP more than a few years. 

> In any case, if your program allows unrestricted array access using a user defined path, the vulnerability already exists, these functions just make it easier to implement the access. 

That’s the rub, right? Array access simply cannot have a user-defined array path today. This feature allows that but as of this reply, the RFC does not disclose the danger of such a thing despite using it in the examples. It’s either irresponsible or naïve.

> If you did not have them and wanted the same functionality you would use a custom implementation (like the one provided by Laravel) and you would have the same vulnerability 
> 
> Cheers
> 
> Carlos

Different frameworks and implementations assign different semantics. I’ve seen dots (such as in laravel), slashes, double back-slashes, etc. over the years. I think dots is a fine choice, but it is worth pointing out that, currently, array keys are binary-safe. These simple looking functions completely ignore that. Even if you escape the dots, now you have two variables: $escaped_key (for use in these functions) and $unescaped_key. 

I see that wildcards are also being considered in the future. Maybe, instead of adding two thin utility functions to global space, it would be better to create an QueryableArray class … kinda like Linq in C# … to handle this type of stuff? Otherwise, this becomes a slippery slope of assigning semantics to random byte sequences.

If you’re going to add query semantics to arrays, do it properly. 

— Rob

---

## #130576 — Hans Krentel — 2026-04-05T11:24:26+00:00

URL: https://externals.io/message/130559#130576 · In reply to: #130569

> 
> 
> 
> > […]
> 
> My point is that this is different and distinct from regular array vulnerabilities and injections.
> 
> $user['data'][$key] !== array_get($user['data'], $key, null);
> 
> In the former 'some.key' is a full key; in the latter, it would access ['some']['key'].

For the sake of this discussion, it would probably make sense to use $dot_path or $dot_pointer instead of $key in this function; this would make the distinction clearer. If I recall correctly, this was already suggested earlier in the discussion—though in the function name, not the parameter name—but I’d have to look it up to find out the exact details.

However, I don’t see any difference from accessing a standard array, apart from the fact that the first parameter contains a container object in the domain and the standard variable on the left-hand side; I wouldn’t expect that !== must be equal to ===.

> 
> Further, the former could be a valid key, but there is no way to access it using the proposed RFC

If I'm not mistaken, this is due to the lack of an escape mechanism, which could very well be intentional—I don't know for sure, but in another thread, Carlos wrote that they want to reconsider this.

And even if it were intentional, without an escape mechanism, it would fall back to the value of the default parameter. Technically speaking, I don’t see a problem here, unless this is unintended or would, in good faith, violate expectations regarding key-value pairs.

Neither of these is a new security issue that you’ve raised—even though, in my opinion, you’ve made good points with your distinctions.

-- hakre

---

## #130578 — Hans Krentel — 2026-04-05T14:11:27+00:00

URL: https://externals.io/message/130559#130578 · In reply to: #130571

> 
> 
> > […]
> 
> Thanks for your comments. I would like to hear what other people think
> about the `null` case. I find it useful but if other people think it is
> unnecessary, it can be easily removed. In any case, the $default would not
> be used in this case

Technically speaking, this scenario does exist; the problem here, if I’m not mistaken, is how to represent or handle it. You originally suggested using the null value for this, which, to my knowledge, is one approach. However, this dilutes the parameter’s meaning, much like it does with “int.” A common and long-established approach is to use only strings for the reference tokens (“keys”).

Since “null” is then the empty string (z-string, empty string, null string), the dot notation in your path can still express this—it would contain neither a dot nor any character—but it would be ambiguous, as it could also mean an empty key for access or just be string zero, just the default string value, e.g. never a name or reference.

JSON Pointer resolves this by prefixing each “key” with the separator; accessing the empty key is then “//” (or “..” in dot-prefix notation for illustration) and accessing the container itself is “/” (or “.” in dot-prefix notation)—the null case discussed here.

For the iterable access discussed (an iterable of reference tokens instead of a string with the dot path), this is then no longer ambiguous, since null, as originally proposed, becomes the empty array and not an array containing the empty string—problem solved. So, if one considers allowing iterables, it becomes possible to avoid the null case and use an empty iterable instead. In this context, the notation [] is probably even more meaningful than null.

I hope these thoughts help you think through the whole thing a bit more carefully. Technically speaking, after removing `null`, there can only be one other `null` case: the empty string. Switching from postfix to prefix notation can help with this and also prevents empty strings entirely; and regardless of the discussion about iterables, removing “null” boils down to the fact that if you want to support both cases: access to the holder’s value and access to the holder’s empty key must be resolved into a single case, and you must specify which case that is, since you cannot express two values for a single value, and keys or any other type of reference must be unique, otherwise they will obviously become unusable too quickly. In my opinion, it makes the most sense to resolve the null case first, since all other specification errors related to ambiguity only arise later (e.g., insufficient escaping rules, conditional access to the existence of a key based on fuzzy logic, etc.) and this provides the precision needed for the cases you want to support, whether it’s postfix or prefix notation or whatever.

In practice, it doesn’t take much effort to pass the array via a placeholder when calling the function:

    $value = array_get_dot([‘’ => $array], ‘.’);

This serves as an example of the null/placeholder/null key scenario in this context and highlights where there might still be some ambiguity with postfix notation.

A third function that lists all dot paths in an array could be helpful for discussing and testing the RFC:

    // The function array_get_dots() returns the array of all dot paths of the array in breadth-first order.
    function array_get_dots(array $array): array { ... }

    $dots = array_get_dots($array);

With a small test data set, simple property tests could be performed, which could then be used as examples in the RFC to formulate the expectations.

The function names in the two listings are for illustrative purposes only.

And yes, in my view, it makes sense to remove “null” and, furthermore, “int” from the first parameter.

Because of the dot notation as shown, the empty string as a value for the dot path should trigger a value error due to an empty dot path, as removing “null” alone does not fully resolve the ambiguity issue for the null string value.

> 
> And, no, no warning will be thrown if any part of the path does not exist,
> being able to easily support not existing paths is one of the main reasons
> for this RFC

Thank you for the clarification!

This is in my opinion good to clarify in the RFC as well, as it is commonly known as error handling, which includes writing what an error is and what is not an error and which diagnostics are guaranteed by the implementation (for example, no warnings/notices.)

--hakre

---

## #130579 — Barel — 2026-04-06T15:01:05+00:00

URL: https://externals.io/message/130559#130579 · In reply to: #130574

Following some comments from some users I have decided to also allow the
$key parameter to be a list of strings/ints so that this functionality can
also be used without using dot notation. I believe this also removes the
need to add any kind of dot escaping. If your segments can contain dots,
just use the form of the function that accepts an array.

It was suggested that accepting an iterable would be a good addition but
none of the array_ functions accept an iterable so I don't think it would
be good to make an exception here

The proposed implementation in GitHub has also been updated with this change

Cheers

Carlos



>
>
>
>
> 
>
> > […]
> elements
> > […]
> away:
> > […]
> null for
> > […]
> easily
> > […]
> the
> > […]
> since the
> > […]
> only
> > […]
> parameter.
> > […]
> all
> > […]
> or
> > […]
> however, I
> > […]
> in
> > […]
> JSON
> > […]
> the
> > […]
> custom
> > […]
> this
> > […]
> PHP
> > […]
> be
> > […]
>
> Yes, I agree, and I suggest we also consider _iterable_ as part of this
> discussion.
>
> Thank you Carlos as well for your work on these functions.
>
> --hakre

---

## #130580 — michal.brzuchalski@gmail.com — 2026-04-06T16:05:20+00:00

URL: https://externals.io/message/130559#130580 · In reply to: #130559

Hi Carlos,

The proposal looks simple on the surface, but it implicitly introduces a
non-trivial policy for interpreting array keys, which is problematic at the
language level.

In PHP, array keys are intentionally loose — any string is a valid key,
including ones containing dots or other separators. Introducing
"array_get()" / "array_has()" with dot-notation means that a plain string
key like "'user.name'" is no longer unambiguously a key; it may be
interpreted as a path. That creates a semantic conflict with existing,
perfectly valid data structures.

This is not just a syntactic concern — it’s a shift in the data model. The
function starts encoding assumptions about how keys should be interpreted,
rather than operating on arrays as they are defined by the language.

We can already see that this space is not universally agreed upon:

- Laravel and Symfony both provide similar helpers, but they use different
path semantics.
- Questions like escaping, null handling, distinguishing “missing key” vs
“null value”, or supporting ArrayAccess / objects are all policy decisions,
not language primitives.

Because of that, these helpers are inherently convention-driven, not
semantically neutral. Different ecosystems solve them differently, which is
a strong signal that this abstraction belongs in userland, where such
conventions can be chosen explicitly and consistently.

Putting this into core would effectively standardize one arbitrary
interpretation of array paths, while PHP arrays themselves do not have such
a concept.

Additionally, allowing "$key" to accept an "array" further weakens the
conceptual model. A variable named "$key" strongly implies a single scalar
identifier, while an array represents a sequence of path segments —
effectively a different abstraction ("path", "segments", etc.). Mixing
these under a single parameter name blurs the intent and makes the API
harder to reason about.

In short:
"array_get()" with path notation does not operate on PHP arrays as defined
— it operates on a particular convention for interpreting keys. That makes
it better suited for userland libraries than for the core language.


Kind regards,
--
Michał Marcin Brzuchalski

sob., 4 kwi 2026, 16:07 użytkownik Barel <barel.barelon@gmail.com> napisał:

> Hi,
>
> I would like to open the discussion on my proposal to add two small,
> focused array functions for retrieving and checking nested array elements
> using dot notation.
>
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has
>
> This is the link to the proposed implementation:
> https://github.com/php/php-src/pull/21637
>
> Thanks!!
>
> Carlos

---

## #130581 — Larry Garfield — 2026-04-06T16:09:03+00:00

URL: https://externals.io/message/130559#130581 · In reply to: #130579

> Following some comments from some users I have decided to also allow 
> the $key parameter to be a list of strings/ints so that this 
> functionality can also be used without using dot notation. I believe 
> this also removes the need to add any kind of dot escaping. If your 
> segments can contain dots, just use the form of the function that 
> accepts an array.
>
> It was suggested that accepting an iterable would be a good addition 
> but none of the array_ functions accept an iterable so I don't think it 
> would be good to make an exception here
>
> The proposed implementation in GitHub has also been updated with this change
>
> Cheers
>
> Carlos

Please remember to bottom post. :-)

It looks like the RFC hasn't been fully updated for array-based "keys" yet.  The function signatures in most of the examples still say string|int|null.

Despite my long-standing and public crusade against arrays being used where an object belongs, I'm overall in favor of this direction.  However, I would go all-in on the array syntax, not the dotted syntax.  There's a few reasons for that.

1. The various notes around escaping.  Having a string instruction format that doesn't handle escaping and encoding and other edge cases is asking for trouble, and it's trouble that will be harder to fix in the future.  String instructions are always more complicated and nuanced than you expect, so a simple "split on the dot and now it's an array!" approach is just too rudimentary to be trustworthy, for all the reasons mentioned in previous posts.

2. If you're not building the path dynamically, then there is little advantage of it over what we have now.

array_get($array, 'foo.bar.1.baz', null);

$array['foo']['bar'][1]['baz'] ?? null

The second may be slightly slower to type because of the punctuation, but it's perfectly viable today.

Where it becomes interesting is when the path is variable... and if the path is variable, I'll probably want to be building it dynamically rather than just selecting one of a few hard-coded options.  And if I'm building it dynamically, then string concatenation is an awful way to do that, for all the escaping reasons mentioned previously.  We're back to concatenating SQL strings together, with all the risk that entails.

So I would be in favor of going all the way to 

function array_get(array $array, array $path, mixed $default = null) {}

Or, for that matter, that is nearly the same as:

function array_get(array $array, array $path) {}

array_get($arr, $path) ?? null;

Which would allow using a variadic for the $path if desired, instead of an array.  I'm not certain that's optimal, but I think it's worth discussing.  array_has() would then follow suit.

Then, separately, I would be in favor of a full-on JSON Pointer implementation that can work on both arrays and JSON blobs, potentially (as the two are effectively isomorphic).  Skip a custom dot notation.  Go straight to the fully robust standard.  Do not pass go, do not collect 200 security reports.

--Larry Garfield

---

## #130582 — Barel — 2026-04-06T16:21:20+00:00

URL: https://externals.io/message/130559#130582 · In reply to: #130581

> 
> > […]
> change
> > […]
>
> Please remember to bottom post. :-)
>
> It looks like the RFC hasn't been fully updated for array-based "keys"
> yet.  The function signatures in most of the examples still say
> string|int|null.
>
> Despite my long-standing and public crusade against arrays being used
> where an object belongs, I'm overall in favor of this direction.  However,
> I would go all-in on the array syntax, not the dotted syntax.  There's a
> few reasons for that.
>
> 1. The various notes around escaping.  Having a string instruction format
> that doesn't handle escaping and encoding and other edge cases is asking
> for trouble, and it's trouble that will be harder to fix in the future.
> String instructions are always more complicated and nuanced than you
> expect, so a simple "split on the dot and now it's an array!" approach is
> just too rudimentary to be trustworthy, for all the reasons mentioned in
> previous posts.
>
> 2. If you're not building the path dynamically, then there is little
> advantage of it over what we have now.
>
> array_get($array, 'foo.bar.1.baz', null);
>
> $array['foo']['bar'][1]['baz'] ?? null
>
> The second may be slightly slower to type because of the punctuation, but
> it's perfectly viable today.
>
> Where it becomes interesting is when the path is variable... and if the
> path is variable, I'll probably want to be building it dynamically rather
> than just selecting one of a few hard-coded options.  And if I'm building
> it dynamically, then string concatenation is an awful way to do that, for
> all the escaping reasons mentioned previously.  We're back to concatenating
> SQL strings together, with all the risk that entails.
>
> So I would be in favor of going all the way to
>
> function array_get(array $array, array $path, mixed $default = null) {}
>
> Or, for that matter, that is nearly the same as:
>
> function array_get(array $array, array $path) {}
>
> array_get($arr, $path) ?? null;
>
> Which would allow using a variadic for the $path if desired, instead of an
> array.  I'm not certain that's optimal, but I think it's worth discussing.
> array_has() would then follow suit.
>
> Then, separately, I would be in favor of a full-on JSON Pointer
> implementation that can work on both arrays and JSON blobs, potentially (as
> the two are effectively isomorphic).  Skip a custom dot notation.  Go
> straight to the fully robust standard.  Do not pass go, do not collect 200
> security reports.
>
> --Larry Garfield
>

Larry,

Thanks for pointing out that I had not updated the example code to include
array in the type, this has now been updated

You raise some interesting points in your message. I would like to hear
what other people think about them

Cheers

Carlos

---

## #130583 — Hans Krentel — 2026-04-07T01:57:24+00:00

URL: https://externals.io/message/130559#130583 · In reply to: #130582

> Larry,
 > [...]
 > You raise some interesting points in your message. I would like to hear
 > what other people think about them

For leaving the default value out so that the splat (or was it spread?) 
operator can be used also in favour.

About JSON Pointer I already wrote, IMHO it should be referenced in the RFC 
prominently, e.g. above the Laravel or other existing implementation 
references as it is an actual standard.

-- hakre

---

## #130607 — Barel — 2026-04-11T10:30:57+00:00

URL: https://externals.io/message/130559#130607 · In reply to: #130580

On Mon, 6 Apr 2026 at 18:05, Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi Carlos,
>
> The proposal looks simple on the surface, but it implicitly introduces a
> non-trivial policy for interpreting array keys, which is problematic at the
> language level.
>
> In PHP, array keys are intentionally loose — any string is a valid key,
> including ones containing dots or other separators. Introducing
> "array_get()" / "array_has()" with dot-notation means that a plain string
> key like "'user.name'" is no longer unambiguously a key; it may be
> interpreted as a path. That creates a semantic conflict with existing,
> perfectly valid data structures.
>
> This is not just a syntactic concern — it’s a shift in the data model. The
> function starts encoding assumptions about how keys should be interpreted,
> rather than operating on arrays as they are defined by the language.
>
> We can already see that this space is not universally agreed upon:
>
> - Laravel and Symfony both provide similar helpers, but they use different
> path semantics.
> - Questions like escaping, null handling, distinguishing “missing key” vs
> “null value”, or supporting ArrayAccess / objects are all policy decisions,
> not language primitives.
>
> Because of that, these helpers are inherently convention-driven, not
> semantically neutral. Different ecosystems solve them differently, which is
> a strong signal that this abstraction belongs in userland, where such
> conventions can be chosen explicitly and consistently.
>
> Putting this into core would effectively standardize one arbitrary
> interpretation of array paths, while PHP arrays themselves do not have such
> a concept.
>
> Additionally, allowing "$key" to accept an "array" further weakens the
> conceptual model. A variable named "$key" strongly implies a single scalar
> identifier, while an array represents a sequence of path segments —
> effectively a different abstraction ("path", "segments", etc.). Mixing
> these under a single parameter name blurs the intent and makes the API
> harder to reason about.
>
> In short:
> "array_get()" with path notation does not operate on PHP arrays as defined
> — it operates on a particular convention for interpreting keys. That makes
> it better suited for userland libraries than for the core language.
>
>
> Kind regards,
> --
> Michał Marcin Brzuchalski
>
> sob., 4 kwi 2026, 16:07 użytkownik Barel <barel.barelon@gmail.com>
> napisał:
>
> > […]
>
After the discussion here and after speaking to other developers, I have
decided to drop the dot notation entirely from this RFC and only leave the
option to use an array path. Using dot (or similar) notations can be easily
achieved using a simple explode or more complex code if we need to do more
complex setups like escaping. The main goal of the RFC has always been
being able to handle dynamic paths. The implementation has also been
updated and is now much simpler

Cheers

Carlos

---

## #130609 — tim@bastelstu.be — 2026-04-12T14:41:22+00:00

URL: https://externals.io/message/130559#130609 · In reply to: #130559

Hi

Am 2026-04-04 16:06, schrieb Barel:
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has

Thank you for your RFC.

I find it not obvious at all that:

- Non-(string|int) path segments will result in the default value being 
returned, rather than a TypeError being thrown or just proceeding with 
implicit coercion.
- Encountering a non-array value along the path will result in the 
default value being returned, rather than an Exception being thrown. 
Returning a default value for an existing path element that is not an 
array feels like a source of error, particularly when any intermediate 
value is an object implementing ArrayAccess.

I would expect the following to hold:

     $path = ['foo', 'bar', 'baz'];
     array_get($array, $path) === array_get(array_get($array, 
array_shift($path), []), $path);

which it will not due to (2).

And the further looking at the examples:

     $array = /* … */;

     array_has($array, ['product', 'name']);
     array_has($array, ['product', 'color']);

Just looking at the code without knowing what the function does, I 
probably would have expected it to be either:

1. `in_array()` operating on multiple values that all need to be there.
2. `array_key_exists()` operating on multiple keys that all need to be 
there.

But not a “path through the array”.

Best regards
Tim Düsterhus

---

Next page: https://externals.io/message/130559.md?page=2