# [RFC][List/Assoc\unique]

- Thread: https://externals.io/message/119070
- Original archive: https://news-web.php.net/php.internals/119070
- Started by Ilija Tovilo on 2022-12-01T18:22:13+00:00
- Messages: 3
- RFC: List\unique() and Assoc\unique() (Inactive) — https://externals.io/rfc/list_assoc_unique.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #119070 — Ilija Tovilo — 2022-12-01T18:22:13+00:00

URL: https://externals.io/message/119070#119070

Hi everyone

After the discussion on adding a new ARRAY_UNIQUE_IDENTICAL flag has
revealed that most would prefer a new function I've decided to create
an RFC for this.

https://wiki.php.net/rfc/list_assoc_unique

This RFC proposes adding two new functions, List\unique() and
Assoc\unique() as alternatives using strict equality (===) semantics,
the former discarding and the latter preserving keys.

Let me know what you think.

Regards,
Ilija

Side note: I *really* hope the discussion will be about more than just
the namespaces.

---

## #119072 — tim@bastelstu.be — 2022-12-01T18:38:44+00:00

URL: https://externals.io/message/119070#119072 · In reply to: #119070

Hi


> https://wiki.php.net/rfc/list_assoc_unique
> 
> This RFC proposes adding two new functions, List\unique() and
> Assoc\unique() as alternatives using strict equality (===) semantics,
> the former discarding and the latter preserving keys.


I believe this would be better solved as part of the more generic 
"expanded iterable helper functions" proposal (which I really hope makes 
it into a proper RFC that is accepted):

https://externals.io/message/118896

Deduplication is reasonably well-defined for arbitrary iterators (even 
infinite iterators) and I don't think iterators (esp. Generators) should 
remain second-class citizens to arrays going forward.

> Side note: I *really* hope the discussion will be about more than just
> the namespaces.
> 

In addition to the reasons above: Yes, adding two new single-function 
namespaces IMO is not a good thing, because it only adds to the 
inconsistency. Adding new namespaces should be part of a "bigger picture".

Best regards
Tim Düsterhus

---

## #119091 — me@jhdxr.com — 2022-12-05T18:52:16+00:00

URL: https://externals.io/message/119070#119091 · In reply to: #119070

Hi Ilija,

Thanks for the RFC. In general, I like the idea but there are certain things not clear to me.

1. What will happen if we pass a list to ` Assoc\unique`? 
```
Assoc\unique([1, 2, 3, 1]);
```

2. What will happen if the array (no matter list or assoc) contains pure value and reference which are strict equal? As the RFC says "references are preserved." 
```
$a = 1;
$arr1 = [$a, &$a];
$arr2 = [&$a, $a];
List\unique($arr1);
List\unique($arr2);
```

3. Currently the RFC (proposal section, function signature) claims the parameter are bool type, which is obvious wrong. But this is just a minor mistake, what I really want to ask here is do we support array only or any array like input?

> Side note: I *really* hope the discussion will be about more than just the namespaces.

Adding two new namespaces with single function doesn't look good to me, especially I cannot think of anything that we may add to these two namespace in the future.

Regards,
CHU Zhaowei