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

Hi Am 2026-04-14 19:06, schrieb Barel:

- I see the point that Tim made about the function names, I have updated them to array_get_path() and array_has_path()

Similarly to Rob's tongue in cheek comment, I think I would also prefer having a common prefix for the functions, since this improves discoverability. While there are some inconsistencies in the array API due to its age, I think there is a reasonably similar precedent with the array_key_*() functions. In fact looking at those, I wonder if the following pair of names would make sense for your proposed feature: - array_path() - array_path_exists() From what I see, the functions in the array API don't mention “get” as the default operation, e.g. it's array_first(), not array_get_first(). And for “existence checks” there's the obvious precedent with array_key_exists() which is also used in the example implementation in your RFC.

- Regarding the issue of returning the default if an intermediate segment is not an array, the philosophy of the function is: if the path exists, return the value, otherwise return the default. This cover uses cases like this: in yaml configuration many times you set a config option to ~ (null) and this many times indicates "use the default config". So you may have something like: database:

    config: ~

Indicating that you want to use the default database config. If you convert this yaml file to an array an use the array_get_path function to get a value, for example array_get_path($config, ['database', 'config', 'port'], 7766), you want to get 7766, not an exception or error. Tim points out that intermediate segments might be objects which implement ArrayAccess, but allowing this would complicate the code of the function a lot without much practical gain.

Perhaps the right solution is using “isset”-like semantics instead: null is treated as an absent entry (it can be debated if an explicit null at the end of the path should be treated as null rather than the default), array allows the traversal to continue and everything else results in a clear error. This would then allow to extend support to anything ArrayAccess in the future without a compatibility break. Generally “throwing an error” is always a safe option. But saying that `array_get_path(['foo' => '???'], ['foo', 'bar'], 'default'); should result in 'default'` doesn't make sense to me and - staying with the config example - might mask configuration errors: As an example, a user might accidentally configure a "DSN":

    database:
        connection: "mysql://root@db.example.com"

when in reality the library expects separate components:

    database:
        connection:
            driver: mysql
            host: db.example.com
            user: root

Now extracting the host with `array_get_path($config, ['database', 'connection', 'host'], 'localhost')` would erroneously fall back to default values instead of reporting a clear error. Best regards Tim Düsterhus