Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130674
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 20 Apr 2026 10:18:16 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <8dca7d45-fce4-4d6a-ac56-956046ef20a6@app.fastmail.com>
In-Reply-To: <4f684a4fbad3a7ddb797e24e3c1a882a@bastelstu.be>
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>
 <4f684a4fbad3a7ddb797e24e3c1a882a@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Apr 19, 2026, at 10:06 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2026-04-18 08:06, schrieb Barel:

>> I am still unconvinced about this. Your proposal seems to give the=20
>> `null`
>> a special value and I think that in general the full semantics are le=
ss
>
> null being a value indicating absence is by no means =E2=80=9Cspecial=E2=
=80=9D in my=20
> suggestion. As previously mentioned, it's the semantics of `isset()`.=20
> It's also what `array_find()` and `array_find_key()` return. It has=20
> special syntax in types with the questionmark in `?Type`. It's what yo=
u=20
> get when you read a non-existent value.
>
>> clear. And I don't really like the function throwing errors for paths=
,=20
>> I
>> think that this function is great for defensive access to values, whe=
re=20
>> you
>> can be sure that you don't need to be checking the path all the time.=20
>> The
>
> Defensive access to me also implies throwing errors *where appropriate=
*,=20
> namely trying to perform an operation that is not meaningful. Trying t=
o=20
> access an array offset on a string is not meaningful and trying to do=20
> *something* is not likely what the user intended to do. Similarly user=
s=20
> passing in `ArrayAccess` objects might reasonably expect them to =E2=80=
=9Cjust=20
> work=E2=80=9D. Returning a default value instead of a clear error will=
 likely=20
> 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 =3D ['foo' =3D> 'bar'];
$val =3D 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 stupidl=
y-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 c=
onvert it to a properly typed object.  These functions are for cases whe=
re those are not viable or convenient options, meaning cases where a giv=
en value could be a string or an array, because the data model author ha=
tes 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 us=
ing ?? or converting to an object or whatever else already.

--Larry Garfield