Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130578
Content-Type: text/plain; charset=utf-8
Message-ID: <1775388386735.2733149565.1017617879@yahoo.de>
To: barel.barelon@gmail.com
Cc: internals@lists.php.net, Aleksander Machniak <alec@alec.pl>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
Date: Sun, 05 Apr 2026 14:11:27 +0000
In-Reply-To: <CABVsiphBPxt92JYz5Qon8rYsdz4m-uwMD8OfU_DFFrC1DV+5EQ@mail.gmail.com>
References: <CABVsiphBPxt92JYz5Qon8rYsdz4m-uwMD8OfU_DFFrC1DV+5EQ@mail.gmail.com>
User-Agent: Vivaldi Mail/7.9.3970.47
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)


On Sunday 05 April 2026 11:31:11 (+02:00), Barel wrote:

> On Sun, 5 Apr 2026 at 08:17, Aleksander Machniak <alec@alec.pl> wrote:
>=20
> > On 4.04.2026 16:06, Barel wrote:
> > > This is the link to the RFC: https://wiki.php.net/rfc/
> > > array_get_and_array_has <
> > https://wiki.php.net/rfc/array_get_and_array_has>
> > I'd prefer $key=3Dnull case removed. It's not that useful, not on pair
> > with array_has(), and one would debate what to do with the $default in
> > this case.
> >
> > I'm not sure this needs to be stated in the RFC, but I hope they do =
not
> > throw a warning when the key does not exist, on any level.
> >
>=20
> Thanks for your comments. I would like to hear what other people think
> about the `null` case. I find it useful but if other people think it is
> unnecessary, it can be easily removed. In any case, the $default would =
not
> be used in this case

Technically speaking, this scenario does exist; the problem here, if =
I=E2=80=99m not mistaken, is how to represent or handle it. You originally =
suggested using the null value for this, which, to my knowledge, is one =
approach. However, this dilutes the parameter=E2=80=99s meaning, much like =
it does with =E2=80=9Cint.=E2=80=9D A common and long-established approach =
is to use only strings for the reference tokens (=E2=80=9Ckeys=E2=80=9D).

Since =E2=80=9Cnull=E2=80=9D is then the empty string (z-string, empty =
string, null string), the dot notation in your path can still express =
this=E2=80=94it would contain neither a dot nor any character=E2=80=94but =
it would be ambiguous, as it could also mean an empty key for access or =
just be string zero, just the default string value, e.g. never a name or =
reference.

JSON Pointer resolves this by prefixing each =E2=80=9Ckey=E2=80=9D with the=
 separator; accessing the empty key is then =E2=80=9C//=E2=80=9D (or =
=E2=80=9C..=E2=80=9D in dot-prefix notation for illustration) and accessing=
 the container itself is =E2=80=9C/=E2=80=9D (or =E2=80=9C.=E2=80=9D in =
dot-prefix notation)=E2=80=94the null case discussed here.

For the iterable access discussed (an iterable of reference tokens instead =
of a string with the dot path), this is then no longer ambiguous, since =
null, as originally proposed, becomes the empty array and not an array =
containing the empty string=E2=80=94problem solved. So, if one considers =
allowing iterables, it becomes possible to avoid the null case and use an =
empty iterable instead. In this context, the notation [] is probably even =
more meaningful than null.

I hope these thoughts help you think through the whole thing a bit more =
carefully. Technically speaking, after removing `null`, there can only be =
one other `null` case: the empty string. Switching from postfix to prefix =
notation can help with this and also prevents empty strings entirely; and =
regardless of the discussion about iterables, removing =
=E2=80=9Cnull=E2=80=9D boils down to the fact that if you want to support =
both cases: access to the holder=E2=80=99s value and access to the =
holder=E2=80=99s empty key must be resolved into a single case, and you =
must specify which case that is, since you cannot express two values for a =
single value, and keys or any other type of reference must be unique, =
otherwise they will obviously become unusable too quickly. In my opinion, =
it makes the most sense to resolve the null case first, since all other =
specification errors related to ambiguity only arise later (e.g., =
insufficient escaping rules, conditional access to the existence of a key =
based on fuzzy logic, etc.) and this provides the precision needed for the =
cases you want to support, whether it=E2=80=99s postfix or prefix notation =
or whatever.

In practice, it doesn=E2=80=99t take much effort to pass the array via a =
placeholder when calling the function:

    $value =3D array_get_dot([=E2=80=98=E2=80=99 =3D> $array], =E2=80=98.=
=E2=80=99);

This serves as an example of the null/placeholder/null key scenario in this=
 context and highlights where there might still be some ambiguity with =
postfix notation.

A third function that lists all dot paths in an array could be helpful for =
discussing and testing the RFC:

    // The function array_get_dots() returns the array of all dot paths of =
the array in breadth-first order.
    function array_get_dots(array $array): array { ... }

    $dots =3D array_get_dots($array);

With a small test data set, simple property tests could be performed, which=
 could then be used as examples in the RFC to formulate the expectations.

The function names in the two listings are for illustrative purposes only.

And yes, in my view, it makes sense to remove =E2=80=9Cnull=E2=80=9D and, =
furthermore, =E2=80=9Cint=E2=80=9D from the first parameter.

Because of the dot notation as shown, the empty string as a value for the =
dot path should trigger a value error due to an empty dot path, as removing=
 =E2=80=9Cnull=E2=80=9D alone does not fully resolve the ambiguity issue =
for the null string value.

>=20
> And, no, no warning will be thrown if any part of the path does not exist=
,
> being able to easily support not existing paths is one of the main =
reasons
> for this RFC

Thank you for the clarification!

This is in my opinion good to clarify in the RFC as well, as it is commonly=
 known as error handling, which includes writing what an error is and what =
is not an error and which diagnostics are guaranteed by the implementation =
(for example, no warnings/notices.)

--hakre