On Sun, Apr 19, 2026, at 10:06 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2026-04-18 08:06, schrieb Barel:
>> I am still unconvinced about this. Your proposal seems to give the
>> `null`
>> a special value and I think that in general the full semantics are less
>
> null being a value indicating absence is by no means “special” in my
> suggestion. As previously mentioned, it's the semantics of `isset()`.
> It's also what `array_find()` and `array_find_key()` return. It has
> special syntax in types with the questionmark in `?Type`. It's what you
> get when you read a non-existent value.
>
>> clear. And I don't really like the function throwing errors for paths,
>> I
>> think that this function is great for defensive access to values, where
>> you
>> can be sure that you don't need to be checking the path all the time.
>> The
>
> Defensive access to me also implies throwing errors *where appropriate*,
> namely trying to perform an operation that is not meaningful. Trying to
> access an array offset on a string is not meaningful and trying to do
> *something* is not likely what the user intended to do. Similarly users
> passing in `ArrayAccess` objects might reasonably expect them to “just
> work”. Returning a default value instead of a clear error will likely
> lead to them thinking they found a bug in PHP.
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?
If so, then I do not agree. The purpose of these functions, as I see it, is
for dealing with inconsistently structured, wonky, arguably stupidly-designed
data. (Which is a lot of REST APIs in the wild, sadly.) If the array were
clearly, consistently, and properly structured, we could reliably just do
$a['foo']['bar'] and move on with life. Or trivially convert it to a properly
typed object. These functions are for cases where those are not viable or
convenient options, meaning cases where a given value could be a string or an
array, because the data model author hates you. (As noted in a previous reply,
I have run into such structures where the value of a JSON key is
string|string{}. It bloody well sucks.)
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?" If that was a distinction that mattered, I'd be using ?? or converting
to an object or whatever else already.
--Larry Garfield
