Hi internals,
I’ve proposed a small RFC to add **is_assoc_array(array $array):** bool to the PHP core.
The function detects associative arrays using internal storage (HT_IS_PACKED).
Similar helpers exist in frameworks, and a native version would be faster and more consistent.
No BC breaks. No impact on SAPIs or OPcache.
Feedback welcome.
Thanks,
Muhammed Arshid
Hey,
On 21.2.2026 03:35:11, Muhammed Arshid KV wrote:
Hi internals,
I’ve proposed a small RFC to add
**is_assoc_array(array $array):** boolto the PHP core.The function detects associative arrays using internal storage (
HT_IS_PACKED).Similar helpers exist in frameworks, and a native version would be faster and more consistent.
No BC breaks. No impact on SAPIs or OPcache.
Feedback welcome.
Thanks,
Muhammed Arshid
What’s the difference between the negation of array_is_list() and is_assoc_array()?
Bob
The fact that this RFC doesn’t even mention PHP’s already available native function (array_is_list() - which performs the inverse) indicates that this initiative is under-researched.
This is the second email of this type frim you in a short period. Please be mindful that a lot of people are subscribed to this mailing list. Suggesting low-value RFCs actually strains human resources and impedes progress.
If you want to create wrapper functions with names that you personally prefer, please create your own library and share that with the public.
Please only submit RFCs for discussion after performing loads of research to ensure that what you want to suggest is actually worth suggesting.
Mick
On 2/20/26 20:35, Muhammed Arshid KV wrote:
Hi internals,
I’ve proposed a small RFC to add *is_assoc_array(array $array):* bool to
the PHP core.The function detects associative arrays using internal storage
*(HT_IS_PACKED)*.Similar helpers exist in frameworks, and a native version would be faster
and more consistent.No BC breaks. No impact on SAPIs or OPcache.
Feedback welcome.
Thanks,
Muhammed Arshid
Your implementation is pretty much the inverse of `zend_array_is_list()`,[^1] so you could probably simplify it with the following (note the negation operator (`!`) in front of `zend_array_is_list(array)`.
PHP_FUNCTION(is_assoc_array)
{
HashTable *array;
ZEND_PARSE_PARAMETERS_START(1, 1)
Z_PARAM_ARRAY_HT(array)
ZEND_PARSE_PARAMETERS_END();
RETURN_BOOL(!zend_array_is_list(array));
}
For the sake of consistency, I would change the name of the function to `array_is_assoc()`.
Cheers,
Ben
[^1]: php-src/Zend/zend_hash.h at da6d890e00d56fd0d842e844aeac03baf7e47f17 · php/php-src · GitHub
Hi
On 2/21/26 03:35, Muhammed Arshid KV wrote:
I’ve proposed a small RFC to add *is_assoc_array(array $array):* bool to
the PHP core.
Besides what the others have already mentioned: Please make sure to fill in the RFC template carefully. Quite a number of sections still contain placeholder values with instructions as to how the section is supposed to be filled in. The “Voting Choices” section is a particular obvious example here.
With regard to the “RFC Impact” section, the RFC mentions:
> Such functions can be replaced with the built-in implementation.
This is not necessarily true. The existing userland function might behave differently to the proposed function.
Even though adding new functions is not considered a BC break as per our policy, there is an expectation to do some research as to what the impact of adding the function would be. Please include this research, the RFC template provides some advice on how to do that.
Please also make sure to include a link to the ML discussion in the References section for future reference. The correct link is this one: php.internals: [RFC] Add is_assoc_array() function
Best regards
Tim Düsterhus
I updated the RFC.
On Sun, 22 Feb 2026, 11:36 pm Tim Düsterhus, <tim@bastelstu.be> wrote:
Hi
On 2/21/26 03:35, Muhammed Arshid KV wrote:
I’ve proposed a small RFC to add is_assoc_array(array $array): bool to
the PHP core.Besides what the others have already mentioned: Please make sure to fill
in the RFC template carefully. Quite a number of sections still contain
placeholder values with instructions as to how the section is supposed
to be filled in. The “Voting Choices” section is a particular obvious
example here.With regard to the “RFC Impact” section, the RFC mentions:
Such functions can be replaced with the built-in implementation.
This is not necessarily true. The existing userland function might
behave differently to the proposed function.Even though adding new functions is not considered a BC break as per our
policy, there is an expectation to do some research as to what the
impact of adding the function would be. Please include this research,
the RFC template provides some advice on how to do that.Please also make sure to include a link to the ML discussion in the
References section for future reference. The correct link is this one:
https://news-web.php.net/php.internals/130115Best regards
Tim Düsterhus