Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131066
Precedence: list
MIME-Version: 1.0
References: <CAEM3Mn3pVE5cJZA0jEm_u63_47fPKfbStsrM=gWcrX30WQ-gSg@mail.gmail.com>
 <ae83e461-5ba4-4100-abd0-17ea82c42e9d@app.fastmail.com> <CAEM3Mn2eJngj6EymLvbxFsF=3X-eq4VvWd7pdFeiOoOViSHCbQ@mail.gmail.com>
 <1c8f3c94-42fe-439f-80b2-6c2273b22f55@app.fastmail.com>
In-Reply-To: <1c8f3c94-42fe-439f-80b2-6c2273b22f55@app.fastmail.com>
Date: Fri, 29 May 2026 20:46:01 +0300
Message-ID: <CAEM3Mn3BbbvhBkWA0K8=t92v8LzYFp9otJoozhX6BQ2vZTD3ZA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC] Null coalescing associative array elements
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: amego2006@gmail.com (Alexander Egorov)

On Fri, May 29, 2026 at 8:14=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> 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 provid=
ed by a 3rd party, not the PHP developer, so it's not the PHP developer's f=
ault that the data format is broken.  But the point stands that we should n=
ot build around that.)

I generally agree with you about broken data formats, but I think it does n=
ot
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 forma=
ts,
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 wa=
y,
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 conve=
nient
tool for that, and not about building around bad data formats.