Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130580
Precedence: list
MIME-Version: 1.0
References: <CABVsipicHroAcWJSEpjwM4+y6p-6axV-6tO__MejThESFVCP3A@mail.gmail.com>
In-Reply-To: <CABVsipicHroAcWJSEpjwM4+y6p-6axV-6tO__MejThESFVCP3A@mail.gmail.com>
Date: Mon, 6 Apr 2026 18:05:20 +0200
Message-ID: <CABdc3WrsYzNd=s5LYkpqphVr_PWVEOyDCcZcC9QkzhKUU7r2ow@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
To: Barel <barel.barelon@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000002e0e064eccd6ff"
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000002e0e064eccd6ff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Carlos,

The proposal looks simple on the surface, but it implicitly introduces a
non-trivial policy for interpreting array keys, which is problematic at the
language level.

In PHP, array keys are intentionally loose =E2=80=94 any string is a valid =
key,
including ones containing dots or other separators. Introducing
"array_get()" / "array_has()" with dot-notation means that a plain string
key like "'user.name'" is no longer unambiguously a key; it may be
interpreted as a path. That creates a semantic conflict with existing,
perfectly valid data structures.

This is not just a syntactic concern =E2=80=94 it=E2=80=99s a shift in the =
data model. The
function starts encoding assumptions about how keys should be interpreted,
rather than operating on arrays as they are defined by the language.

We can already see that this space is not universally agreed upon:

- Laravel and Symfony both provide similar helpers, but they use different
path semantics.
- Questions like escaping, null handling, distinguishing =E2=80=9Cmissing k=
ey=E2=80=9D vs
=E2=80=9Cnull value=E2=80=9D, or supporting ArrayAccess / objects are all p=
olicy decisions,
not language primitives.

Because of that, these helpers are inherently convention-driven, not
semantically neutral. Different ecosystems solve them differently, which is
a strong signal that this abstraction belongs in userland, where such
conventions can be chosen explicitly and consistently.

Putting this into core would effectively standardize one arbitrary
interpretation of array paths, while PHP arrays themselves do not have such
a concept.

Additionally, allowing "$key" to accept an "array" further weakens the
conceptual model. A variable named "$key" strongly implies a single scalar
identifier, while an array represents a sequence of path segments =E2=80=94
effectively a different abstraction ("path", "segments", etc.). Mixing
these under a single parameter name blurs the intent and makes the API
harder to reason about.

In short:
"array_get()" with path notation does not operate on PHP arrays as defined
=E2=80=94 it operates on a particular convention for interpreting keys. Tha=
t makes
it better suited for userland libraries than for the core language.


Kind regards,
--
Micha=C5=82 Marcin Brzuchalski

sob., 4 kwi 2026, 16:07 u=C5=BCytkownik Barel <barel.barelon@gmail.com> nap=
isa=C5=82:

> Hi,
>
> I would like to open the discussion on my proposal to add two small,
> focused array functions for retrieving and checking nested array elements
> using dot notation.
>
> This is the link to the RFC:
> https://wiki.php.net/rfc/array_get_and_array_has
>
> This is the link to the proposed implementation:
> https://github.com/php/php-src/pull/21637
>
> Thanks!!
>
> Carlos
>

--000000000000002e0e064eccd6ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Carlos,<div dir=3D"auto"><br></div><div dir=3D"auto">T=
he proposal looks simple on the surface, but it implicitly introduces a non=
-trivial policy for interpreting array keys, which is problematic at the la=
nguage level.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In PHP, ar=
ray keys are intentionally loose =E2=80=94 any string is a valid key, inclu=
ding ones containing dots or other separators. Introducing &quot;array_get(=
)&quot; / &quot;array_has()&quot; with dot-notation means that a plain stri=
ng key like &quot;&#39;<a href=3D"http://user.name">user.name</a>&#39;&quot=
; is no longer unambiguously a key; it may be interpreted as a path. That c=
reates a semantic conflict with existing, perfectly valid data structures.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">This is not just a synta=
ctic concern =E2=80=94 it=E2=80=99s a shift in the data model. The function=
 starts encoding assumptions about how keys should be interpreted, rather t=
han operating on arrays as they are defined by the language.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">We can already see that this space is=
 not universally agreed upon:</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">- Laravel and Symfony both provide similar helpers, but they use diff=
erent path semantics.</div><div dir=3D"auto">- Questions like escaping, nul=
l handling, distinguishing =E2=80=9Cmissing key=E2=80=9D vs =E2=80=9Cnull v=
alue=E2=80=9D, or supporting ArrayAccess / objects are all policy decisions=
, not language primitives.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Because of that, these helpers are inherently convention-driven, not sem=
antically neutral. Different ecosystems solve them differently, which is a =
strong signal that this abstraction belongs in userland, where such convent=
ions can be chosen explicitly and consistently.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Putting this into core would effectively standardiz=
e one arbitrary interpretation of array paths, while PHP arrays themselves =
do not have such a concept.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Additionally, allowing &quot;$key&quot; to accept an &quot;array&quot; =
further weakens the conceptual model. A variable named &quot;$key&quot; str=
ongly implies a single scalar identifier, while an array represents a seque=
nce of path segments =E2=80=94 effectively a different abstraction (&quot;p=
ath&quot;, &quot;segments&quot;, etc.). Mixing these under a single paramet=
er name blurs the intent and makes the API harder to reason about.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">In short:</div><div dir=3D"auto"=
>&quot;array_get()&quot; with path notation does not operate on PHP arrays =
as defined =E2=80=94 it operates on a particular convention for interpretin=
g keys. That makes it better suited for userland libraries than for the cor=
e language.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Kind regards,</div><div dir=3D"auto">--</div><div dir=3D"au=
to">Micha=C5=82 Marcin Brzuchalski</div></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">sob., 4 kwi 2=
026, 16:07 u=C5=BCytkownik Barel &lt;<a href=3D"mailto:barel.barelon@gmail.=
com">barel.barelon@gmail.com</a>&gt; napisa=C5=82:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>I would like to ope=
n the discussion on my proposal to add two small, focused array functions f=
or retrieving and checking nested array elements using dot notation.<br><br=
>This is the link to the RFC:=C2=A0<a href=3D"https://wiki.php.net/rfc/arra=
y_get_and_array_has" target=3D"_blank" rel=3D"noreferrer">https://wiki.php.=
net/rfc/array_get_and_array_has</a><br><br>This is the link to the proposed=
 implementation:=C2=A0<a href=3D"https://github.com/php/php-src/pull/21637"=
 target=3D"_blank" rel=3D"noreferrer">https://github.com/php/php-src/pull/2=
1637</a></div><div><br></div><div>Thanks!!</div><div><br></div><div>Carlos<=
/div></div>
</blockquote></div>

--000000000000002e0e064eccd6ff--