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
