Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128957
Precedence: list
MIME-Version: 1.0
References: <CAE1541vPXkgZsxfAiWJyosnhDksGT=2tDJyoYOcJtG16jZh9nA@mail.gmail.com>
 <4b605609-47c2-4df5-be71-8b962ad9ff1e@varteg.nz>
In-Reply-To: <4b605609-47c2-4df5-be71-8b962ad9ff1e@varteg.nz>
Date: Fri, 24 Oct 2025 16:51:34 -0700
Message-ID: <CAE1541vL=D2ni1L+Hg-WzuWdNcKHMwRoq64PeEgzSRmJ3_kAVQ@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC proposal for adding SORT_STRICT flag to array_unique()
To: Weedpacket@varteg.nz
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000068d7410641f03b29"
From: jmarble@intuitivetechnology.com (Jason Marble)

--00000000000068d7410641f03b29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Correct! Basically:
- SORT_STRINGS: reliable and predictable when you understand the value will
be converted to a string
- SORT_NUMERIC: same but _risky_, you should be certain you're working with
numbers
- SORT_REGULAR: the sort is unstable and will inevitably cause a bug that
no one will understand LOL

With the proposed SORT_STRICT, we will get super fast, reliable and
predictable deduplication.


On Fri, Oct 24, 2025 at 3:16=E2=80=AFPM Morgan <Weedpacket@varteg.nz> wrote=
:

> On 2025-10-25 08:34, Jason Marble wrote:
> > Hello everybody!
> >
> >
> > The potential for a `SORT_NATURAL` flag also came to mind as another
> > useful addition, but I believe `SORT_STRICT` is the more critical
> > feature to discuss first.
> >
>
> I know I find array_unique generally useless due to its insistence on
> stringifying everything for comparison.
>
> ```
> $uniques =3D [];
> foreach($source_array as $a) {
>      if(!in_array($a, $uniques, true)) {
>          $uniques[] =3D $a;
>      }
> }
> ```
>
> I seem to recall part of the issue is that array_unique works by sorting
> its elements so that "equal" values are adjacent. I know this would be
> done on O(n log(n)) vs. O(n^2) grounds, but that could be addressed at
> least in part by a smarter sort criterion that sorts by type/class (in
> some arbitrary order) before sorting by value. For uncomparable types
> (i.e., instances of most classes) this would be by object ID, because we
> don't _actually_ care about ordering.
>

--00000000000068d7410641f03b29
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Correct! Basically:<br>- SORT_STRINGS: reliable and p=
redictable when you understand the value will be converted to a string<br>-=
 SORT_NUMERIC: same but _risky_, you should be certain you&#39;re working w=
ith numbers<br>- SORT_REGULAR: the sort is unstable and will inevitably cau=
se a bug that no one will understand LOL</div><div><br>With the proposed SO=
RT_STRICT, we will get super fast, reliable and predictable deduplication.<=
br><br></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Oct 24, 2025 at 3:16=E2=80=AFPM Morga=
n &lt;<a href=3D"mailto:Weedpacket@varteg.nz">Weedpacket@varteg.nz</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2025-1=
0-25 08:34, Jason Marble wrote:<br>
&gt; Hello everybody!<br>
&gt; <br>
&gt; <br>
&gt; The potential for a `SORT_NATURAL` flag also came to mind as another <=
br>
&gt; useful addition, but I believe `SORT_STRICT` is the more critical <br>
&gt; feature to discuss first.<br>
&gt; <br>
<br>
I know I find array_unique generally useless due to its insistence on <br>
stringifying everything for comparison.<br>
<br>
```<br>
$uniques =3D [];<br>
foreach($source_array as $a) {<br>
=C2=A0 =C2=A0 =C2=A0if(!in_array($a, $uniques, true)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$uniques[] =3D $a;<br>
=C2=A0 =C2=A0 =C2=A0}<br>
}<br>
```<br>
<br>
I seem to recall part of the issue is that array_unique works by sorting <b=
r>
its elements so that &quot;equal&quot; values are adjacent. I know this wou=
ld be <br>
done on O(n log(n)) vs. O(n^2) grounds, but that could be addressed at <br>
least in part by a smarter sort criterion that sorts by type/class (in <br>
some arbitrary order) before sorting by value. For uncomparable types <br>
(i.e., instances of most classes) this would be by object ID, because we <b=
r>
don&#39;t _actually_ care about ordering.<br>
</blockquote></div></div>

--00000000000068d7410641f03b29--