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 <[email protected]> wrote: > > > > > On Sunday 05 April 2026 11:43:03 (+02:00), Barel wrote: > > > On Sun, 5 Apr 2026 at 10:13, Hans Krentel <[email protected]> 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 >
