[PHP-DEV] [RFC] [Discussion] array_get and array_has functions

Mailing Lists php.internals
1

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

2

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.comas 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

3

Hi Carlos,

This sounds interesting.

A mature solution used in JS is lodash, with the get and has functions:

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

On Sat, Apr 4, 2026 at 5:08 PM Barel <barel.barelon@gmail.com> wrote:

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

4

On 04/04/2026 15:06, Barel wrote:

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: PHP: rfc:array_get_and_array_has

This is the link to the proposed implementation: Array_get and array_has functions by carlos-granados · Pull Request #21637 · php/php-src · GitHub

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)

5

On 4.04.2026 16:06, Barel wrote:

This is the link to the RFC: PHP: rfc array_get_and_array_has <PHP: 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

6

On Sat, Apr 4, 2026, at 16:06, Barel wrote:

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

7

On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:

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:
PHP: rfc:array_get_and_array_has

This is the link to the proposed implementation:
Array_get and array_has functions by carlos-granados · Pull Request #21637 · php/php-src · GitHub

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.

8

On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote:

On Sat, Apr 4, 2026, at 16:06, Barel wrote:
> 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: PHP: rfc:array_get_and_array_has
>
> This is the link to the proposed implementation: Array_get and array_has functions by carlos-granados · Pull Request #21637 · php/php-src · GitHub
>
> 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.

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

9

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:

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

On Sat, Apr 4, 2026 at 5:08 PM Barel <barel.barelon@gmail.com> wrote:

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

10

On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote:

On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote:

On Sat, Apr 4, 2026, at 16:06, Barel wrote:

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.

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

11

On Sat, 4 Apr 2026 at 20:15, AllenJB <php.lists@allenjb.me.uk> wrote:

On 04/04/2026 15:06, Barel wrote:

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)

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

12

On Sun, 5 Apr 2026 at 08:17, Aleksander Machniak <alec@alec.pl> wrote:

On 4.04.2026 16:06, Barel wrote:

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.

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

13

On Sun, 5 Apr 2026 at 08:54, Rob Landers rob@bottled.codes wrote:

On Sat, Apr 4, 2026, at 16:06, Barel wrote:

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

14

On Sun, 5 Apr 2026 at 10:13, Hans Krentel <hanskrentel@yahoo.de> wrote:

On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:

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.

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

15

On Sunday 05 April 2026 11:43:03 (+02:00), Barel wrote:

On Sun, 5 Apr 2026 at 10:13, Hans Krentel <hanskrentel@yahoo.de> wrote:

>
> On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:
>
> > 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:
> > PHP: rfc:array_get_and_array_has
> >
> > This is the link to the proposed implementation:
> > Array_get and array_has functions by carlos-granados · Pull Request #21637 · php/php-src · GitHub
> >
> > 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.
>

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

16

On Sun, Apr 5, 2026, at 11:34, Barel wrote:

On Sun, 5 Apr 2026 at 08:54, Rob Landers rob@bottled.codes wrote:

On Sat, Apr 4, 2026, at 16:06, Barel wrote:

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.

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

17

On Sunday 05 April 2026 11:12:02 (+02:00), Rob Landers wrote:

On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote:
>
>
>
>
> On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote:
>
> > On Sat, Apr 4, 2026, at 16:06, Barel wrote:
> > > 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: PHP: rfc:array_get_and_array_has
> > >
> > > This is the link to the proposed implementation: Array_get and array_has functions by carlos-granados · Pull Request #21637 · php/php-src · GitHub
> > >
> > > 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.
>
> 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'].

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

18

On Sunday 05 April 2026 11:31:11 (+02:00), Barel wrote:

On Sun, 5 Apr 2026 at 08:17, Aleksander Machniak <alec@alec.pl> wrote:

> On 4.04.2026 16:06, Barel wrote:
> > This is the link to the RFC: PHP: rfc
> > array_get_and_array_has <
> PHP: 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

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

19

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

On Sun, 5 Apr 2026 at 12:52, Hans Krentel <hanskrentel@yahoo.de> wrote:

On Sunday 05 April 2026 11:43:03 (+02:00), Barel wrote:

On Sun, 5 Apr 2026 at 10:13, Hans Krentel <hanskrentel@yahoo.de> wrote:

On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:

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.

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

20

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