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

Tim, Many thanks for your comments regarding the RFC, I have updated it. Regarding the issue of throwing errors if a path cannot be traversed due to an intermediate step not being an array, I tend to agree with Larry so I am leaving this as it is for the time being Cheers Carlos On Mon, 20 Apr 2026 at 19:07, Tim Düsterhus <tim@bastelstu.be> wrote: > Hi > > Am 2026-04-20 17:18, schrieb Larry Garfield: > > Just to make sure we're talking about the same thing here. Tim, you're > > suggesting that this: > > > > $a = ['foo' => 'bar']; > > $val = array_path_get($a, ['foo', 'bar', 'baz']); > > > > Should error rather than returning null? > > Yes. > > > If the array were clearly, consistently, and properly structured, we > > could reliably just do $a['foo']['bar'] and move on with life. > > […] > > So in that sort of case, I'm not sure it's useful to distinguish > > between "There is no baz key on the array at foo.bar" and "foo.bar is a > > string, not an array, wat?" […] > > The goal of the RFC is replacing > $a['foo']['bar'] where the *path is > dynamic*. Quoting right from the introduction of the RFC: > > > When the structure of the array is known in advance and the exact > > element to retrieve is hardcoded, existing PHP syntax works well […] > > And quoting further from the introduction: > > > array_path_get() retrieves a value from a deeply nested array and > > returns a default value if the path does not exist. > > I'm arguing that a “(value at) path does not exist” is something > fundamentally different from “value encountered on path cannot be > traversed further”. > > > converting to an object > > I agree that the correct solution in the general case is “use a proper > object mapper” (such as Valinor) and don't see much personal value in > having the proposed functions. But if they exist, I would want them to > behave as safely as possible and that includes erroring if they cannot > make sense of the data. Emitting a Warning when encountering an > improperly typed value across the path would also work for me, but I > suppose that others won't be in favor of *that* :-) > > Best regards > Tim Düsterhus >