Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130607 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id A10E11A00BC for ; Sat, 11 Apr 2026 10:31:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1775903477; bh=pE273s4XbpPMtx/SLGNOXD22J+L80wYi0uBZ7ck85Yc=; h=References:In-Reply-To:From:Date:Subject:To:From; b=WoA7W+zWosu1IEjOypEO9mVwVjVzT/G9BDJqKJNzO29WoCw/xXVxvBX+U1jSvYdGU /A0vVSymgWCOdajmi4FacB8CUZpoC84qX0ELD14KmMlLuGAT8UGblDxtSJnmslLlJ3 0gPGef2PKiHei9ZlESrPLeXIijwbqmKikyIkgLbUsIwupJJHQZDvIqkPU6HIYFxl+z N97i53ieX+06XWOWGweK+W3IfTwZFWwEH1tUhUZa80b6LWBRu+e12JOAW19Ixkfvtu 57YhYKqGQFsjjINvHjXDb20Zi9d76hucf/77xe6pgbvtlPJaKAMo71fAllMu1TXHhV zNMbbxLVCIKPw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DFC4A18005D for ; Sat, 11 Apr 2026 10:31:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 11 Apr 2026 10:31:15 +0000 (UTC) Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-899d6b7b073so28119936d6.2 for ; Sat, 11 Apr 2026 03:31:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775903470; cv=none; d=google.com; s=arc-20240605; b=c+jpVQDZDmar66obcq4LuWKhs9u7ahrKlyf0E8z/l/olr/vrTSIaPt28LrJw4gWE0n IJRTusKIbRShA0sA3fRLJyGHnkp6JR6EPt/85SYmc+un4afozicsu8mXbEtRL6c0UEFt jCpf6EAVeS/E9nlVWiUOXNtbnOPzF2rUeVN6qFcbEr4OjWpaH/jPzHY3ZUuYZDKrNYA/ +RXcL/1YCuhRAAKNWkE2lcn6BKZWW76dyZd1pQ0OK+uTuUV6Or4IDDfBgzWG2l9NRYeO sRE/qFNu9szA056YMjodqrr0wUyAf1BodPwKOHWjGnu7x5Y540VibWL6y4s45id8UKOD h9rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=pE273s4XbpPMtx/SLGNOXD22J+L80wYi0uBZ7ck85Yc=; fh=PwvV1jWZOR90rDIG/6XexqaHJyAFBTdnFVhsS64qdEQ=; b=HMY8rOTs9Nj3QdCzb8IUlteMT07Ez0F2dg1vSoTDlCv6173CtGVzwRXBM0As4SUf1+ HPYA3uhvcahz2IyHKEdXaWk9CEjOmiadPaAZi84CIpMMw+jyxzzmJP4SFfco8sBFreYo uOeWJaP6McfFrVsnWKuELQsiq/GpRdXVO4Pjuw7w9DYYjCkSSaZ1lmDhTL2HoBPjPcHE I4nOTuBbLZKcmALlnkPRxl14WdNrFssa1oSzG95LyLzIUSAcSSE24JsHpS/+3LvqAUE9 2TkdmjIKHaLBY6NvGZdgVlZ/S9F6I4tOaD43RRNoiv5WhypHPA40E0kr3a5WGYzhk/6b VTYg==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775903470; x=1776508270; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=pE273s4XbpPMtx/SLGNOXD22J+L80wYi0uBZ7ck85Yc=; b=SJZDK/1k7FBBWZziUR/io6/crtjgUrU2TcqY5j1nK0Y/iF/JBGY5UlegxlNh+tXyPB fZMJHS0Q404wyIb/v1wj3wBHOCNpr3cpp9FRn0yPA6lmhg6owo13UWiNEtZ3CBlHgj+5 p3pzVjsTMMw3BPB0EOCiagZvrhKO6c08Yog5eECjxVC6VK/FnIzHGrvOc3Km1Dik2WAd meCov6img4T9VVAPgh4Gsbuj62K7CMRaqkzwzEdPWqAgYlIEO7pgS8as6ecxE1ME+8NY 97l6HjT3AZSJ8QfPQDYcDqgT8ARLBXfJX5TUGo9qPXEefGbmom/Z2159wpiuuUjcFnGn 3gCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775903470; x=1776508270; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pE273s4XbpPMtx/SLGNOXD22J+L80wYi0uBZ7ck85Yc=; b=nbYYUIla43lVSeAfFuzGCP/me2UrPAgzjS9xPnfD3h20/lY9nrLLv7kjSdYS1CjX43 RGLpmV0JEcDjlM6spZyGrLutQv9WV6stLxLS928ze3eK3xW3k5yxWIx77rQVIMeQjiXz ClcPoorPSYXx1yWlqs7xhu3e1N3o6pMh/lmMqv+l+R4rPXN2lbbS40pNHdu0xX5JjWgp WU0svQc+zsJcfg7h4D/Je4G+9glYHAjJLuirg8sJP09XCXAVEi9aj46r8agMDBlS3MI3 +NyUT8RJ5EjoZVyxkMPKipGzZKtqxOLUvSbcrGW4zJLPcsuwbRgUXw76b6f4e49+OpqV mYOQ== X-Gm-Message-State: AOJu0YyfHdRvjWjUxb2HlzefpGtnhMPv3nblDE3NQF8TYfn3my8OYiti PcDylLo3MDyHBFQwU0Sk9hpJKwIyHTfMPfkO2XhmdU3kTubyJiZV7YO5t3YZrV492B9WV52PWI9 eKXq7qTOAhX4SGEsZtq1HE+zxCde/oWDnKw== X-Gm-Gg: AeBDieuTGex6P6VEMc6rt0UN77GNfES5wBHs3H06AH9dVFnTCxCez4DuU8eBgWGZaUX AiBZOcJ8aHBMcfrCBQmVrDAHhg/soPGo3sGQZIEbzxo+UpKjfomZVFUT6mM096TjRktxFa9h35L tHJ2RQuyVcfaUEga87MbNNZ4ViVqDvQYFZTsJ/uxbVJ5bW7CM9a8k+5AW+CeRjb1SWVPkugL4I4 IgCOZ0RA81S6XqKWidqy7gKWL9QiHsriS2JqE3oYkewaqFf/h+qQSY3Dt6H201EbmYp9oOaEBzw rRzX/X5mf7sBqaAq5tSSpipjXKTyOz/PK5yGxw== X-Received: by 2002:a05:6214:27c1:b0:8a0:846e:8850 with SMTP id 6a1803df08f44-8ac861d7f86mr97392476d6.20.1775903469659; Sat, 11 Apr 2026 03:31:09 -0700 (PDT) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 11 Apr 2026 12:30:57 +0200 X-Gm-Features: AQROBzBlcQPBbCQpcDK6zXY-GUtlLwbD_O5gp1cWpJQ6sYEBUQe_HPKhaKTlTFY Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions To: PHP internals Content-Type: multipart/alternative; boundary="00000000000076eb11064f2cbf1b" From: barel.barelon@gmail.com (Barel) --00000000000076eb11064f2cbf1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 6 Apr 2026 at 18:05, Micha=C5=82 Marcin Brzuchalski < michal.brzuchalski@gmail.com> wrote: > 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 t= he > language level. > > In PHP, array keys are intentionally loose =E2=80=94 any string is a vali= d 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 th= e 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 differen= t > path semantics. > - Questions like escaping, null handling, distinguishing =E2=80=9Cmissing= key=E2=80=9D vs > =E2=80=9Cnull value=E2=80=9D, or supporting ArrayAccess / objects are all= policy 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 su= ch > a concept. > > Additionally, allowing "$key" to accept an "array" further weakens the > conceptual model. A variable named "$key" strongly implies a single scala= r > 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 define= d > =E2=80=94 it operates on a particular convention for interpreting keys. T= hat 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 > napisa=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 element= s >> 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 >> > After the discussion here and after speaking to other developers, I have decided to drop the dot notation entirely from this RFC and only leave the option to use an array path. Using dot (or similar) notations can be easily achieved using a simple explode or more complex code if we need to do more complex setups like escaping. The main goal of the RFC has always been being able to handle dynamic paths. The implementation has also been updated and is now much simpler Cheers Carlos --00000000000076eb11064f2cbf1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 6 Apr 2= 026 at 18:05, Micha=C5=82 Marcin Brzuchalski <michal.brzuchalski@gmail.com> wrote:
=
Hi Carl= os,

The proposal looks simple = on the surface, but it implicitly introduces a non-trivial policy for inter= preting array keys, which is problematic at the language level.

In PHP, array keys are intentionall= y 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 co= ncern =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 ope= rating on arrays as they are defined by the language.

We can already see that this space is not uni= versally agreed upon:

- = Laravel and Symfony both provide similar helpers, but they use different pa= th semantics.
- Questions like escaping, null handli= ng, distinguishing =E2=80=9Cmissing key=E2=80=9D vs =E2=80=9Cnull value=E2= =80=9D, or supporting ArrayAccess / objects are all policy decisions, not l= anguage primitives.

Beca= use of that, these helpers are inherently convention-driven, not semantical= ly neutral. Different ecosystems solve them differently, which is a strong = signal that this abstraction belongs in userland, where such conventions ca= n be chosen explicitly and consistently.

<= div dir=3D"auto">Putting this into core would effectively standardize one a= rbitrary interpretation of array paths, while PHP arrays themselves do not = have such a concept.

Add= itionally, allowing "$key" to accept an "array" further= weakens the conceptual model. A variable named "$key" strongly i= mplies a single scalar identifier, while an array represents a sequence of = path segments =E2=80=94 effectively a different abstraction ("path&quo= t;, "segments", etc.). Mixing these under a single parameter name= blurs the intent and makes the API harder to reason about.

In short:
&quo= t;array_get()" with path notation does not operate on PHP arrays as de= fined =E2=80=94 it operates on a particular convention for interpreting key= s. That makes it better suited for userland libraries than for the core lan= guage.


Kind regards,
--
M= icha=C5=82 Marcin Brzuchalski

sob., 4 kwi 2026, 16:07 u=C5=BCytkownik = Barel <bare= l.barelon@gmail.com> napisa=C5=82:
Hi,

I would l= ike to open the discussion on my proposal to add two small, focused array f= unctions for retrieving and checking nested array elements using dot notati= on.

This is the link to the RFC:=C2=A0https:/= /wiki.php.net/rfc/array_get_and_array_has

This is the link to th= e proposed implementation:=C2=A0https://github.com/php/php-= src/pull/21637

Thanks!!

Carlos

Af= ter the discussion here and after speaking to other developers, I have deci= ded to drop the dot notation entirely from this RFC and only leave the opti= on to use an array path. Using dot (or similar) notations can be easily ach= ieved using a simple explode or more complex code if we need to do more com= plex setups like escaping. The main goal of the RFC has always been being a= ble to handle dynamic=C2=A0paths. The implementation has also been updated = and is now much simpler

Cheers

Carlos=C2=A0
--00000000000076eb11064f2cbf1b--