On Fri, May 29, 2026 at 8:14 PM Larry Garfield <[email protected]> wrote: > > On Fri, May 29, 2026, at 11:58 AM, Alexander Egorov wrote: > > > array_filter will only cover the cases when you need to filter all > > fields by the same criteria (null's in this case). > > But it does not fit the case when you still have some mandatory fields > > even if they are null, but some are optional. > > At least in the simplest form, but otherwise in more complex forms > > we'll still come up with additional code. > > A data format that has a mix of required-even-if-null and optional fields is > a broken data format. We should not design language features around a broken > data format. (I realize that the broken data format is often provided by a > 3rd party, not the PHP developer, so it's not the PHP developer's fault that > the data format is broken. But the point stands that we should not build > around that.)
I generally agree with you about broken data formats, but I think it does not really relate to the language feature itself. The reason and motivation why I'm suggesting this feature is not to promote building around broken data formats, but to have a convenient syntax for what is anyway being done more or less often. It is always developer's decision or necessity to do things this or that way, and PHP anyway (as any other language) allows developers to have whatever data-structures they want without obligation to do things "right", because "right" is often very relative. The language is first and foremost an instrument. Specifically, associative arrays by themselves are completely decoupled from what exactly they are used for, and PHP anyway allows to dynamically add or remove (unset) keys from them. So, the feature I'm suggesting is about having a more convenient tool for that, and not about building around bad data formats.
