Everything

php

[RFC] array_only() and array_except() – Utility functions for array key filtering

php.internals

Muhammed Arshid KV

193 days ago

Hello Internals,

I would like to propose a new RFC titled *array_only() and array_except()*.

RFC: https://wiki.php.net/rfc/array_only_except
<https://wiki.php.net/rfc/array_only_except?utm_source=chatgpt.com>

This RFC proposes adding two utility functions to the PHP core:

• array_only(array $array, array $keys): array
• array_except(array $array, array $keys): array

These functions allow selecting or excluding specific keys from an array.

Similar helpers are commonly used in frameworks, and adding native support
would improve readability and consistency in userland code.

Summary:

• array_only() returns a new array containing only the specified keys.
• array_except() returns a new array excluding the specified keys.
• Original array is not modified.
• Works with associative and numeric keys.
• No impact on SAPIs or on OPcache.

I would appreciate feedback and suggestions from the community.
If there is general agreement, I plan to move the RFC forward.

Thanks,
Muhammed Arshid KV

Claude Pache

193 days ago

> Le 20 févr. 2026 à 10:25, Muhammed Arshid KV <arshidkv12@gmail.com> a écrit :
>
> Hello Internals,
>
> I would like to propose a new RFC titled array_only() and array_except().
>
> RFC: https://wiki.php.net/rfc/array_only_except <https://wiki.php.net/rfc/array_only_except?utm_source=chatgpt.com>
> This RFC proposes adding two utility functions to the PHP core:
>
> • array_only(array $array, array $keys): array
> • array_except(array $array, array $keys): array
>
> These functions allow selecting or excluding specific keys from an array.
>
> Similar helpers are commonly used in frameworks, and adding native support would improve readability and consistency in userland code.
>
> Summary:
>
> • array_only() returns a new array containing only the specified keys.
> • array_except() returns a new array excluding the specified keys.
> • Original array is not modified.
> • Works with associative and numeric keys.
> • No impact on SAPIs or on OPcache.
>
> I would appreciate feedback and suggestions from the community.
> If there is general agreement, I plan to move the RFC forward.
>
> Thanks,
> Muhammed Arshid KV
>

Hi,

The principle of the RFC is interesting to me, as it is a situation I encounter from time to time. Two remarks:

1. It may be interesting to compare with currently available solutions. Currently, I use  `array_intersect_key` and `array_diff_key` when I need the semantics of proposed `array_only` and `array_except`:

```php
array_intersect_key($data, ['id' => null, 'email' => null]);
```

2. I think that the name of the new functions ought to make evident that we are filtering on keys and not on something else. I suggest: `array_only_keys` and `array_except_keys`.

—Claude

mickmackusa

193 days ago

Muhammed Arshid KV

193 days ago

Hi,

Thanks for the feedback.

1. Yes, *array_intersect_key() *and *array_diff_key() *can be used today,
but the RFC proposes dedicated functions for better readability, less
boilerplate, and potentially better performance and lower memory usage by
avoiding temporary arrays.

2. Good point about naming. Making the key-filtering behavior explicit
(e.g., *array_only_keys* and *array_except_keys*) improves clarity and
avoids confusion.

On Fri, 20 Feb 2026, 3:38 pm Claude Pache, <claude.pache@gmail.com> wrote:

Tim Düsterhus

191 days ago

Hi

The same comments as with your other RFC apply here.

On 2/20/26 18:37, Muhammed Arshid KV wrote:

> 1. Yes, *array_intersect_key() *and *array_diff_key() *can be used today,
> but the RFC proposes dedicated functions for better readability, less
> boilerplate, and potentially better performance and lower memory usage by
> avoiding temporary arrays.

Can you elaborate on what you mean by “lower memory usage by avoiding
temporary arrays”?

> 2. Good point about naming. Making the key-filtering behavior explicit
> (e.g., *array_only_keys* and *array_except_keys*) improves clarity and
> avoids confusion.

I don't think that `array_(only|except)_keys()` is particularly clear.
From the naming I would expect it to return the array keys / values
(i.e. do the same as `array_keys()` and `array_values()` respectively).

Best regards
Tim Düsterhus

Muhammed Arshid KV

191 days ago

Hi,

Here is a simple example of an `array_only()` implementation using existing
PHP functions:

```php
function array_only(array $input, array $keys): array {
return array_intersect_key($input, array_flip($keys));
}
```

This works, but `array_flip($keys)` creates an extra temporary hash table.
So peak memory becomes: input + keys + flipped array + result.

In a native C implementation, we can iterate over `$keys` and copy values
directly into the result without creating that temporary array. That means
fewer allocations and lower peak memory usage, especially with large key
sets or inside loops.

Thanks.


On Sun, 22 Feb 2026, 11:55 pm Tim Düsterhus, <tim@bastelstu.be> wrote:

Tim Düsterhus

184 days ago

Hi

Am 2026-02-22 19:58, schrieb Muhammed Arshid KV:

> Here is a simple example of an `array_only()` implementation using
> existing
> PHP functions:
>
> ```php
> function array_only(array $input, array $keys): array {
>     return array_intersect_key($input, array_flip($keys));
> }
> ```
>
> This works, but `array_flip($keys)` creates an extra temporary hash
> table.
> So peak memory becomes: input + keys + flipped array + result.

That is true for this specific implementation of a “wrapper function”.
It is not necessarily true for other implementations, e.g. simply using
the functions directly instead of creating a wrapper for two method
calls. `array_flip()` supports compile-time evaluation, so you can just
write:

$dataWithOnlyIdAndEmail = \array_intersect_key($data,
\array_flip(['id', 'email']));

and OPcache will make sure to rewrite it to:

$dataWithOnlyIdAndEmail = \array_intersect_key($data, ['id' => 0,
'email' => 1]);

avoiding the intermediate array.

Best regards
Tim Düsterhus

PS: It appears that the RFC is not listed in the overview at
https://wiki.php.net/rfc.

Muhammed Arshid KV

184 days ago

Hi Tim,

Thanks for the explanation.

In this example,

$dataWithOnlyIdAndEmail = \array_intersect_key($data, ['id' => 0, 'email'
=> 1]);

the second argument is an associative array.

But in my *array_only(array $input, array $keys) *function, *$keys* is
a *numeric
array.* Working with a *numeric array* may be slightly faster than building
an associative array first.

Just wanted to clarify that point.

Best regards,

Muhammed Arshid KV

On Sun, 1 Mar 2026, 7:40 pm Tim Düsterhus, <tim@bastelstu.be> wrote:

Muhammed Arshid KV

180 days ago

Hi,

I think the RFC *“array_only_except”* is ready to move to the voting phase.

If there are no further objections or required changes, I would like to
proceed with starting the vote.

Thanks.

Ben Ramsey

177 days ago

On 3/4/26 23:23, Muhammed Arshid KV wrote:

> Hi,
>
> I think the RFC *“array_only_except”* is ready to move to the voting
> phase.
>
> If there are no further objections or required changes, I would like
> to proceed with starting the vote.
>
> Thanks.
>

Unless I've missed something, I don't think the RFC has addressed any of
the feedback from the discussion on this list.

Claude Pache suggested:

> It may be interesting to compare with currently available solutions.

And Mick suggested something similar:

> the RFC doesn't even acknowledge the fact that PHP already has
> native functions which serve the exact same purpose

On the list you acknowledged `array_intersect_key()` and
`array_diff_key()`, saying:

> the RFC proposes dedicated functions for better readability, less
> boilerplate, and potentially better performance and lower memory
> usage.

I would have expected all of this to be added to the RFC to provide
further rationale for why these new functions are needed, along with
some numbers to back up the better performance and lower memory usage
claims.

In another reply to the list, you seemed to indicate that you were going
to change the names of the functions in the RFC:

> Good point about naming. Making the key-filtering behavior explicit
> (e.g., array_only_keys and array_except_keys) improves clarity and
> avoids confusion.

Did you decide against changing the names in the RFC? I don't see any
updates to that effect.

I'd like to see the feedback addressed within the RFC before opening it
for a vote. It think it would make the RFC stronger.

Cheers,
Ben

Muhammed Arshid KV

177 days ago

Hi

>Unless I've missed something, I don't think the RFC has addressed any of

the feedback from the discussion on this list.

Thank you for the feedback and for taking the time to review the RFC.

I have updated the RFC to address the points raised in the discussion.

Please have a look when you have a chance and let me know if anything still
needs improvement.

Regards

Muhammed Arshid