Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128962
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 25 Oct 2025 10:40:49 +0200
To: internals@lists.php.net
Message-ID: <c0bfa1b3-49a0-4d1f-bc5c-79361c3d8ef5@app.fastmail.com>
In-Reply-To: <48b2d4f5-2baa-4dac-9f13-163ac68a4adf@app.fastmail.com>
References: 
 <CAE1541vPXkgZsxfAiWJyosnhDksGT=2tDJyoYOcJtG16jZh9nA@mail.gmail.com>
 <48b2d4f5-2baa-4dac-9f13-163ac68a4adf@app.fastmail.com>
Subject: Re: [PHP-DEV] RFC proposal for adding SORT_STRICT flag to array_unique()
Content-Type: multipart/alternative;
 boundary=064498101e9c4e3185d43e2f42571ff0
From: rob@bottled.codes ("Rob Landers")

--064498101e9c4e3185d43e2f42571ff0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Oct 25, 2025, at 10:23, Rob Landers wrote:
> On Fri, Oct 24, 2025, at 21:34, Jason Marble wrote:
>> Hello everybody!
>>=20
>> I'd like to open a discussion regarding the behavior of `array_unique=
()` with the `SORT_REGULAR` flag when used on arrays containing mixed ty=
pes.
>>=20
>> Currently, `SORT_REGULAR` uses non-strict comparisons, which can lead=
 to unintentional data loss when values like `100` and `"100"` are treat=
ed as duplicates. This forces developers to implement user-land workarou=
nds.
>>=20
>> Here is a common scenario where this behavior is problematic:
>>=20
>> ```php
>> $events =3D [
>>     ['id' =3D> 100, 'type' =3D> 'user.login'],        // User event (=
int)
>>     ['id' =3D> "100", 'type' =3D> 'system.migration'],  // System eve=
nt (string)
>>     ['id' =3D> 100, 'type' =3D> 'user.login'],        // Duplicate us=
er event
>> ];
>>=20
>> $event_ids =3D array_column($events, 'id'); // [100, "100", 100]
>>=20
>> // Current behavior with SORT_REGULAR
>> $unique_ids =3D array_unique($event_ids, SORT_REGULAR); // Result: [1=
00]
>> // The string "100" is lost due to type coercion.
>> ```
>>=20
>> To address this, I propose adding a new flag, `SORT_STRICT`, which wo=
uld use strict (`=3D=3D=3D`) comparisons to differentiate between values=
 of different types.
>>=20
>> With the new flag, the result would be:
>>=20
>> ```php
>> // Proposed behavior with SORT_STRICT
>> $unique_ids =3D array_unique($event_ids, SORT_STRICT); // Result: [10=
0, "100"]
>> // Both integer and string values are preserved.
>> ```
>>=20
>> I've already submitted a PR to correct the bug I just highlighted:
>> PR: https://github.com/php/php-src/pull/20273
>> The potential for a `SORT_NATURAL` flag also came to mind as another =
useful addition, but I believe `SORT_STRICT` is the more critical featur=
e to discuss first.
>>=20
>> I look forward to your feedback.
>>=20
>> Thanks, =20
>> - Jason
>=20
> Hi Jason,
>=20
> Other than the bytes in memory and how they=E2=80=99re laid out, I fai=
l to see how 100 is different from 100. They=E2=80=99re conceptually ide=
ntical, and array_* functions generally behave by value, not by identity=
. I think it=E2=80=99s probably wise to take a step back here and evalua=
te the knock-on effects of something like this:
>=20
> SORT_REGULAR has some warts, it isn=E2=80=99t perfect. Having a SORT_S=
TRICT sounds kinda nice until you start thinking about it a bit. This pa=
rameter has traditionally been used to indicate a "comparison mode" that=
 describes how to compare values. Strict identity is on a completely dif=
ferent axis (they can=E2=80=99t be less/greater than; objects aren=E2=80=
=99t *strictly* comparable, but they=E2=80=99re loosely comparable, 1.0 =
is strictly comparable to 1 or "1"). Further, it begs the question: "can=
 I get a SORT_STRICT_NUMERIC" or "can I get a SORT_STRICT_STRING", which=
 further indicates this is a completely different axis altogether than "=
just" a different comparison mode.
>=20
> As to your example, it conflates two namespaces of Ids =E2=80=94 user =
ids and system ids =E2=80=94 into a single untyped bag, then asks array_=
unique() to preserve that boundary. This is a domain distinction, not a =
language problem. Simply removing your array_column() step in your examp=
le arrives at your desired solution.
>=20
> =E2=80=94 Rob

I mis-typed this:

> they can=E2=80=99t be less/greater than; objects aren=E2=80=99t *stric=
tly* comparable, but they=E2=80=99re loosely comparable, 1.0 is strictly=
 comparable to 1 or "1"

It should have read:

> they can=E2=80=99t be less/greater than; objects aren=E2=80=99t *stric=
tly* comparable, but they=E2=80=99re loosely comparable, 1.0 is *not* st=
rictly comparable to 1 or "1"

PS. Speaking of "bytes in memory", it might be better to propose a SORT_=
BINARY. It has the same effect you=E2=80=99re looking for, but arrays of=
 bytes have a lexicographical ordering.

=E2=80=94 Rob
--064498101e9c4e3185d43e2f42571ff0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Oct 25, 2025, at 10:23, Rob Landers wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, Oct 24, 20=
25, at 21:34, Jason Marble wrote:</div><blockquote type=3D"cite" id=3D"q=
t-qt" style=3D""><div dir=3D"ltr"><div><div><div>Hello everybody!</div><=
div><br></div><div>I'd like to open a discussion regarding the behavior =
of `array_unique()` with the `SORT_REGULAR` flag when used on arrays con=
taining mixed types.</div><div><br></div><div>Currently, `SORT_REGULAR` =
uses non-strict comparisons, which can lead to unintentional data loss w=
hen values like `100` and `"100"` are treated as duplicates. This forces=
 developers to implement user-land workarounds.</div><div><br></div><div=
>Here is a common scenario where this behavior is problematic:</div><div=
><br></div><div>```php</div><div>$events =3D [</div><div>&nbsp; &nbsp; [=
'id' =3D&gt; 100, 'type' =3D&gt; 'user.login'],&nbsp; &nbsp; &nbsp; &nbs=
p; // User event (int)</div><div>&nbsp; &nbsp; ['id' =3D&gt; "100", 'typ=
e' =3D&gt; 'system.migration'],&nbsp; // System event (string)</div><div=
>&nbsp; &nbsp; ['id' =3D&gt; 100, 'type' =3D&gt; 'user.login'],&nbsp; &n=
bsp; &nbsp; &nbsp; // Duplicate user event</div><div>];</div><div><br></=
div><div>$event_ids =3D array_column($events, 'id'); // [100, "100", 100=
]</div><div><br></div><div>// Current behavior with SORT_REGULAR</div><d=
iv>$unique_ids =3D array_unique($event_ids, SORT_REGULAR); // Result: [1=
00]</div><div>// The string "100" is lost due to type coercion.</div><di=
v>```</div><div><br></div><div>To address this, I propose adding a new f=
lag, `SORT_STRICT`, which would use strict (`=3D=3D=3D`) comparisons to =
differentiate between values of different types.</div><div><br></div><di=
v>With the new flag, the result would be:</div><div><br></div><div>```ph=
p</div><div>// Proposed behavior with SORT_STRICT</div><div>$unique_ids =
=3D array_unique($event_ids, SORT_STRICT); // Result: [100, "100"]</div>=
<div>// Both integer and string values are preserved.</div><div>```</div=
><div><br></div><div>I've already submitted a PR to correct the bug I ju=
st highlighted:</div><div>PR:&nbsp;<a href=3D"https://github.com/php/php=
-src/pull/20273" target=3D"_blank">https://github.com/php/php-src/pull/2=
0273</a></div></div><div><div>The potential for a `SORT_NATURAL` flag al=
so came to mind as another useful addition, but I believe `SORT_STRICT` =
is the more critical feature to discuss first.</div><div><br></div><div>=
I look forward to your feedback.</div><div><br></div><div>Thanks,&nbsp;&=
nbsp;<span class=3D"qt-color" style=3D"color:rgb(136, 136, 136);"><br>- =
Jason</span></div></div></div></div></blockquote><div><br></div><div>Hi =
Jason,</div><div><br></div><div>Other than the bytes in memory and how t=
hey=E2=80=99re laid out, I fail to see how 100 is different from 100. Th=
ey=E2=80=99re conceptually identical, and array_* functions generally be=
have by value, not by identity. I think it=E2=80=99s probably wise to ta=
ke a step back here and evaluate the knock-on effects of something like =
this:</div><div><br></div><div>SORT_REGULAR has some warts, it isn=E2=80=
=99t perfect. Having a SORT_STRICT sounds kinda nice until you start thi=
nking about it a bit. This parameter has traditionally been used to indi=
cate a "comparison mode" that describes how to compare values. Strict id=
entity is on a completely different axis (they can=E2=80=99t be less/gre=
ater than; objects aren=E2=80=99t <b>strictly</b> comparable, but they=E2=
=80=99re loosely comparable, 1.0 is strictly comparable to 1 or "1"). Fu=
rther, it begs the question: "can I get a SORT_STRICT_NUMERIC" or "can I=
 get a SORT_STRICT_STRING", which further indicates this is a completely=
 different axis altogether than "just" a different comparison mode.</div=
><div><br></div><div>As to your example, it conflates two namespaces of =
Ids =E2=80=94 user ids and system ids =E2=80=94 into a single untyped ba=
g, then asks array_unique() to preserve that boundary. This is a domain =
distinction, not a language problem. Simply removing your array_column()=
 step in your example arrives at your desired solution.</div><div><br></=
div><div id=3D"qt-sig121229152">=E2=80=94 Rob</div></blockquote><div><br=
></div><div>I mis-typed this:</div><div><br></div><blockquote type=3D"ci=
te"><div>they can=E2=80=99t be less/greater than; objects aren=E2=80=99t=
 <b>strictly</b> comparable, but they=E2=80=99re loosely comparable, 1.0=
 is strictly comparable to 1 or "1"<br></div></blockquote><div><br></div=
><div>It should have read:</div><div><br></div><blockquote type=3D"cite"=
><div>they can=E2=80=99t be less/greater than; objects aren=E2=80=99t <b=
>strictly</b> comparable, but they=E2=80=99re loosely comparable, 1.0 is=
&nbsp;<b>not</b> strictly comparable to 1 or "1"<br></div></blockquote><=
div><br></div><div>PS. Speaking of "bytes in memory", it might be better=
 to propose a SORT_BINARY. It has the same effect you=E2=80=99re looking=
 for, but arrays of bytes have a lexicographical ordering.</div><div><br=
></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--064498101e9c4e3185d43e2f42571ff0--