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:
>
> > 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=null 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.
> >
>
> 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’m 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’s meaning, much like it does with “int.” A common and long-established approach is to use only strings for the reference tokens (“keys”).
Since “null” is then the empty string (z-string, empty string, null string), the dot notation in your path can still express this—it would contain neither a dot nor any character—but 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 “key” with the separator; accessing the empty key is then “//” (or “..” in dot-prefix notation for illustration) and accessing the container itself is “/” (or “.” in dot-prefix notation)—the 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—problem 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 “null” boils down to the fact that if you want to support both cases: access to the holder’s value and access to the holder’s 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’s postfix or prefix notation or whatever.
In practice, it doesn’t take much effort to pass the array via a placeholder when calling the function:
$value = array_get_dot([‘’ => $array], ‘.’);
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 = 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 “null” and, furthermore, “int” 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 “null” alone does not fully resolve the ambiguity issue for the null string value.
>
> 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
