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

Hi Am 2026-04-18 08:06, schrieb Barel:

array_path_exists. I have preferred to keep get in the function name because I think that array_path is less clear about what the function does. RFC and implementation have been updated.

No strong preference regarding the _get() suffix from my side.

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.

existing implementations in Laravel and Lodash do not throw any error if an intermediate value is not an array (or object for Lodash) and instead return the default, so I think it is best to keep this behaviour

I don't think that lodash is quite comparable here, because JavaScript is quite different to PHP in that *everything* is an object. Thus _.get({"foo": "bar"}, "foo.length.toString") is meaningful (namely it returns Number.prototype.toString()). As for the Laravel comparison, from what I see, they *do* support any ArrayAccess, so the function is also not comparable. I've also taken another look at the RFC and have the following additional comments: - The “Invalid array path segments” example is outdated, stdClass in the path should throw. - The types of the path-segments should be pre-validated for consistent error reporting. Meaning:

    array_path_get($array, ['foo', 'bar', new stdClass()])

should consistently throw, independent of whether $array is [], ["foo" => []], ["foo" => ["bar" => []] or something else. - I also wonder if $path should just be string[] instead of (int|string)[]. In the context of array keys, "123" is equivalent to 123 anyways. Best regards Tim Düsterhus