Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121671
MIME-Version: 1.0
References: <CAB-BujYUueXGAi+Mz1xjmy_AWGJy2VLzf6_rk3_O1tqaEbQ92w@mail.gmail.com>
 <CA+p1FaYk4_M+cczv8yRvefyfNhpPfcYMrQGc1x+S1Ai7-x_j=g@mail.gmail.com>
 <CAB-Bujb8g+g7OL34hBy+6LtLDiH9aXdrkZo7KdnAxhMs1FNjsA@mail.gmail.com>
 <CAB-BujaOckOXFBrWF2DbBmwSEcp2Y-9vZu_c=uxnDQc5=Va0eA@mail.gmail.com> <CA+p1FabQXDf-KV22Um=FoM6aQA=e7+i3kuAUaYf5bgJDU05+sQ@mail.gmail.com>
In-Reply-To: <CA+p1FabQXDf-KV22Um=FoM6aQA=e7+i3kuAUaYf5bgJDU05+sQ@mail.gmail.com>
Date: Tue, 14 Nov 2023 13:45:15 +0100
Message-ID: <CAB-BujYcRmAsS1T747=yuZWJHfLjDfFP_YRBae+Bnp9wT2iH=w@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Array functions with strict comparison
From: andreas@dqxtech.net (Andreas Hennings)

On Tue, 14 Nov 2023 at 02:08, David Gebler <davidgebler@gmail.com> wrote:
>
> On Sun, Nov 12, 2023 at 8:20=E2=80=AFPM Andreas Hennings <andreas@dqxtech=
.net>
> wrote:
>
> > So to me, this alone is an argument to implement this natively.
> > The other argument is that it is kind of sad how the current functions
> > don't behave as one would expect.
>
>
> I'd expect there to be a larger and proportionately increasing performanc=
e
> difference between array_diff versus array_udiff with callback or a
> userland array_diff_strict function the larger the datasets you feed in.
> But I'm not sure how common either the use case of diffing arrays of 25,0=
00
> or 250,000 elements might be, or needing this comparison to be strict
> equality. I suspect the use case where both these conditions apply is ver=
y
> rare.

The idea is to use the new functions in general-purpose algorithms
without worrying about type coercion or scaling.

>
> But if you want to create an RFC, please go for it. You could add an extr=
a
> parameter to these functions after the input arrays, which was a flag for
> strict comparison. Whether such a thing with a default value of non-stric=
t
> (so not BC breaking) would be considered preferable to new global
> functions, I'm not sure. I'd probably go with new functions but maybe
> someone else will weigh in with their thoughts.

The extra parameter does not really work for array_diff() or
array_intersect(), because these have variadic parameters.
Or at least it would not be "clean".
Technically we could just check if the last parameter is an array or
not, and if not, we use it as a control flag.
But I don't really like it that much, I prefer clean signatures.