On Mon, 6 Apr 2026 at 18:05, Michał Marcin Brzuchalski <
[email protected]> 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 the
> language level.
>
> In PHP, array keys are intentionally loose — 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 — it’s 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 “missing key” vs
> “null value”, 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 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 —
> 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
> — it operates on a particular convention for interpreting keys. That makes
> it better suited for userland libraries than for the core language.
>
>
> Kind regards,
> --
> Michał Marcin Brzuchalski
>
> sob., 4 kwi 2026, 16:07 użytkownik Barel <[email protected]>
> napisał:
>
>> 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
>>
>
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
