Re: RFC proposal for adding SORT_STRICT flag to array_unique()

Quick POC: https://github.com/jmarble/php-src/tree/feature/array-unique-sort-strict ~1.4x faster than this simple userland implementation on my local machine. I purposefully avoided implementing a hash-bucket because I had already tried that and encountered too many edge cases LOL: https://gist.github.com/jmarble/1e08eb15274cd434e867baf96ffa301d On Fri, Oct 24, 2025 at 4:51 PM Jason Marble < jmarble@intuitivetechnology.com> wrote: > 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 PM 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 = []; >> foreach($source_array as $a) { >> if(!in_array($a, $uniques, true)) { >> $uniques[] = $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. >> >