Re: [RFC] [Discussion] array_get and array_has functions

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