On Mon, Apr 6, 2026, at 10:01 AM, Barel wrote:
> 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
