Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128954
Precedence: list
MIME-Version: 1.0
Date: Fri, 24 Oct 2025 12:34:36 -0700
Message-ID: <CAE1541vPXkgZsxfAiWJyosnhDksGT=2tDJyoYOcJtG16jZh9nA@mail.gmail.com>
Subject: [PHP-DEV] RFC proposal for adding SORT_STRICT flag to array_unique()
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000006aa1930641eca433"
From: jmarble@intuitivetechnology.com (Jason Marble)

--0000000000006aa1930641eca433
Content-Type: text/plain; charset="UTF-8"

Hello everybody!

I'd like to open a discussion regarding the behavior of `array_unique()`
with the `SORT_REGULAR` flag when used on arrays containing mixed types.

Currently, `SORT_REGULAR` uses non-strict comparisons, which can lead to
unintentional data loss when values like `100` and `"100"` are treated as
duplicates. This forces developers to implement user-land workarounds.

Here is a common scenario where this behavior is problematic:

```php
$events = [
    ['id' => 100, 'type' => 'user.login'],        // User event (int)
    ['id' => "100", 'type' => 'system.migration'],  // System event (string)
    ['id' => 100, 'type' => 'user.login'],        // Duplicate user event
];

$event_ids = array_column($events, 'id'); // [100, "100", 100]

// Current behavior with SORT_REGULAR
$unique_ids = array_unique($event_ids, SORT_REGULAR); // Result: [100]
// The string "100" is lost due to type coercion.
```

To address this, I propose adding a new flag, `SORT_STRICT`, which would
use strict (`===`) comparisons to differentiate between values of different
types.

With the new flag, the result would be:

```php
// Proposed behavior with SORT_STRICT
$unique_ids = array_unique($event_ids, SORT_STRICT); // Result: [100, "100"]
// Both integer and string values are preserved.
```

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 feature to
discuss first.

I look forward to your feedback.

Thanks,
- Jason

--0000000000006aa1930641eca433
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello everybody!<br><br>I&#39;d like to open a d=
iscussion regarding the behavior of `array_unique()` with the `SORT_REGULAR=
` flag when used on arrays containing mixed types.<br><br>Currently, `SORT_=
REGULAR` uses non-strict comparisons, which can lead to unintentional data =
loss when values like `100` and `&quot;100&quot;` are treated as duplicates=
. This forces developers to implement user-land workarounds.<br><br>Here is=
 a common scenario where this behavior is problematic:<br><br>```php<br>$ev=
ents =3D [<br>=C2=A0 =C2=A0 [&#39;id&#39; =3D&gt; 100, &#39;type&#39; =3D&g=
t; &#39;user.login&#39;],=C2=A0 =C2=A0 =C2=A0 =C2=A0 // User event (int)<br=
>=C2=A0 =C2=A0 [&#39;id&#39; =3D&gt; &quot;100&quot;, &#39;type&#39; =3D&gt=
; &#39;system.migration&#39;],=C2=A0 // System event (string)<br>=C2=A0 =C2=
=A0 [&#39;id&#39; =3D&gt; 100, &#39;type&#39; =3D&gt; &#39;user.login&#39;]=
,=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Duplicate user event<br>];<br><br>$event_id=
s =3D array_column($events, &#39;id&#39;); // [100, &quot;100&quot;, 100]<b=
r><br>// Current behavior with SORT_REGULAR<br>$unique_ids =3D array_unique=
($event_ids, SORT_REGULAR); // Result: [100]<br>// The string &quot;100&quo=
t; is lost due to type coercion.<br>```<br><br>To address this, I propose a=
dding a new flag, `SORT_STRICT`, which would use strict (`=3D=3D=3D`) compa=
risons to differentiate between values of different types.<br><br>With the =
new flag, the result would be:<br><br>```php<br>// Proposed behavior with S=
ORT_STRICT<br>$unique_ids =3D array_unique($event_ids, SORT_STRICT); // Res=
ult: [100, &quot;100&quot;]<br>// Both integer and string values are preser=
ved.<br>```<br><br>I&#39;ve already submitted a PR to correct the bug I jus=
t highlighted:<br>PR:=C2=A0<a href=3D"https://github.com/php/php-src/pull/2=
0273" target=3D"_blank">https://github.com/php/php-src/pull/20273</a><br><b=
r></div><div>The potential for a `SORT_NATURAL` flag also came to mind as a=
nother useful addition, but I believe `SORT_STRICT` is the more critical fe=
ature to discuss first.<br><br>I look forward to your feedback.<br><br>Than=
ks,=C2=A0=C2=A0<font color=3D"#888888"><br>- Jason</font></div></div><div><=
br></div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div><div></div></div></div></div></div>

--0000000000006aa1930641eca433--