Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130667
Precedence: list
MIME-Version: 1.0
Date: Sun, 19 Apr 2026 17:06:19 +0200
To: Barel <barel.barelon@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
In-Reply-To: <CABVsiph+=CeAkAL6XwzD57qDPt=24r8sh4HV32BOPmRFXfTqSw@mail.gmail.com>
References: <CABVsipicHroAcWJSEpjwM4+y6p-6axV-6tO__MejThESFVCP3A@mail.gmail.com>
 <CABdc3WrsYzNd=s5LYkpqphVr_PWVEOyDCcZcC9QkzhKUU7r2ow@mail.gmail.com>
 <CABVsipgfS2j49iBm38X8g1N1RdVZfHudaBqBrdNLfTMpUZfC2w@mail.gmail.com>
 <f0a77882-44e2-4cd9-be14-eca9163194ca@app.fastmail.com>
 <CABVsipjQiay5NK36Rwtwk6tDi0mRwa+Wv4oSz17qR_vwresYfw@mail.gmail.com>
 <19d58a46b50222b75da4e40e417efd05@bastelstu.be>
 <CABVsiph+=CeAkAL6XwzD57qDPt=24r8sh4HV32BOPmRFXfTqSw@mail.gmail.com>
Message-ID: <4f684a4fbad3a7ddb797e24e3c1a882a@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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