Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128961
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 25 Oct 2025 10:23:06 +0200
To: internals@lists.php.net
Message-ID: <48b2d4f5-2baa-4dac-9f13-163ac68a4adf@app.fastmail.com>
In-Reply-To: 
 <CAE1541vPXkgZsxfAiWJyosnhDksGT=2tDJyoYOcJtG16jZh9nA@mail.gmail.com>
References: 
 <CAE1541vPXkgZsxfAiWJyosnhDksGT=2tDJyoYOcJtG16jZh9nA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC proposal for adding SORT_STRICT flag to array_unique()
Content-Type: multipart/alternative;
 boundary=9b8f16086c724537aa71284cff4fdc1a
From: rob@bottled.codes ("Rob Landers")

--9b8f16086c724537aa71284cff4fdc1a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 typ=
es.
>=20
> Currently, `SORT_REGULAR` uses non-strict comparisons, which can lead =
to unintentional data loss when values like `100` and `"100"` are treate=
d as duplicates. This forces developers to implement user-land workaroun=
ds.
>=20
> Here is a common scenario where this behavior is problematic:
>=20
> ```php
> $events =3D [
>     ['id' =3D> 100, 'type' =3D> 'user.login'],        // User event (i=
nt)
>     ['id' =3D> "100", 'type' =3D> 'system.migration'],  // System even=
t (string)
>     ['id' =3D> 100, 'type' =3D> 'user.login'],        // Duplicate use=
r 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: [10=
0]
> // The string "100" is lost due to type coercion.
> ```
>=20
> To address this, I propose adding a new flag, `SORT_STRICT`, which wou=
ld 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: [100=
, "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 u=
seful addition, but I believe `SORT_STRICT` is the more critical feature=
 to discuss first.
>=20
> I look forward to your feedback.
>=20
> Thanks, =20
> - Jason

Hi Jason,

Other than the bytes in memory and how they=E2=80=99re laid out, I fail =
to see how 100 is different from 100. They=E2=80=99re conceptually ident=
ical, 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 evaluate=
 the knock-on effects of something like this:

SORT_REGULAR has some warts, it isn=E2=80=99t perfect. Having a SORT_STR=
ICT sounds kinda nice until you start thinking about it a bit. This para=
meter has traditionally been used to indicate a "comparison mode" that d=
escribes how to compare values. Strict identity is on a completely diffe=
rent axis (they can=E2=80=99t be less/greater than; objects aren=E2=80=99=
t *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 fu=
rther indicates this is a completely different axis altogether than "jus=
t" a different comparison mode.

As to your example, it conflates two namespaces of Ids =E2=80=94 user id=
s and system ids =E2=80=94 into a single untyped bag, then asks array_un=
ique() to preserve that boundary. This is a domain distinction, not a la=
nguage problem. Simply removing your array_column() step in your example=
 arrives at your desired solution.

=E2=80=94 Rob
--9b8f16086c724537aa71284cff4fdc1a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, Oct =
24, 2025, at 21:34, Jason Marble wrote:</div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div dir=3D"ltr"><div><div><div>Hello everybody!</di=
v><div><br></div><div>I'd like to open a discussion regarding the behavi=
or of `array_unique()` with the `SORT_REGULAR` flag when used on arrays =
containing mixed types.</div><div><br></div><div>Currently, `SORT_REGULA=
R` uses non-strict comparisons, which can lead to unintentional data los=
s when values like `100` and `"100"` are treated as duplicates. This for=
ces 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; &=
nbsp; // User event (int)</div><div>&nbsp; &nbsp; ['id' =3D&gt; "100", '=
type' =3D&gt; 'system.migration'],&nbsp; // System event (string)</div><=
div>&nbsp; &nbsp; ['id' =3D&gt; 100, 'type' =3D&gt; 'user.login'],&nbsp;=
 &nbsp; &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=
><div>$unique_ids =3D array_unique($event_ids, SORT_REGULAR); // Result:=
 [100]</div><div>// The string "100" is lost due to type coercion.</div>=
<div>```</div><div><br></div><div>To address this, I propose adding a ne=
w flag, `SORT_STRICT`, which would use strict (`=3D=3D=3D`) comparisons =
to differentiate between values of different types.</div><div><br></div>=
<div>With the new flag, the result would be:</div><div><br></div><div>``=
`php</div><div>// Proposed behavior with SORT_STRICT</div><div>$unique_i=
ds =3D array_unique($event_ids, SORT_STRICT); // Result: [100, "100"]</d=
iv><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=
 just 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/pul=
l/20273</a></div></div><div><div>The potential for a `SORT_NATURAL` flag=
 also came to mind as another useful addition, but I believe `SORT_STRIC=
T` is the more critical feature to discuss first.</div><div><br></div><d=
iv>I look forward to your feedback.</div><div><br></div><div>Thanks,&nbs=
p;&nbsp;<span class=3D"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"sig121229152">=E2=80=94 Rob</div></body></html>
--9b8f16086c724537aa71284cff4fdc1a--