Take SORT_REGULAR behind the woodshed?

[jmarble]

Many of you may be blissfully unaware, but PHP's SORT_REGULAR is fundamentally flawed and leads to unpredictable results, especially when used with array_unique() as it's currently implemented in Collection->unique().

I submitted a PR to the Laravel framework with a partial attempt to fix the issue. After much consideration, I feel we need to take SORT_REGULAR behind the woodshed and accept correctness over micro optimization. But we don't have to revert to the original in_array -- there are better solutions.

If we all prefer to be typestict for Collection->unique() by default, we can be both fast and correct. The alternative, is a little slowdown by default (non-typestrict by default), but correct, as opposed to the current fast and mostly kinda correct.

See: #57480

Also see my new PR that at least gives us a performant solution for us who can't accept SORT_REGULAR: #57517

[macropay-solutions]

Question is why is Laravel using

return new static(array_unique($this->items, SORT_REGULAR));
instead of
return new static(array_unique($this->items)); ?

UPDATE
Maybe because the second one would call __toString on each model and thus json encode the model and that is slower.

But a simple online search reveals:

Using array_unique($this->items, SORT_REGULAR) on an array of objects is unreliable and may produce unexpected results. This is because array_unique() internally sorts the array to efficiently detect duplicates, but PHP objects are not comparable using < or >. As a result, the sort order becomes inconsistent or undefined, causing duplicates to be missed. Even if objects are identical in content or are the same instance, SORT_REGULAR does not guarantee correct deduplication due to this sorting instability. The behavior can vary depending on array size and object types, making it appear random.

[jmarble]

Because SORT_REGULAR is like a "cheat code" for native uniqueness in an array that contains types that can't be cast to string.

PHP's type-juggling is amazing, until it's not.

[macropay-solutions]

@jmarble still the Eloquent collection is using the same SORT_REGULAR and that deals with models(objects)

Update

    public function unique($key = null, $strict = false)
    {
        if (!is_null($key)) {
            return parent::unique($key, $strict);
        }

        return new static(array_values($this->getDictionary()));
    }

It does that only when key is not null

[macropay-solutions]

And this is a reason why they don't support composed pks. Because this relies on the PK for the uniqueness :)

Update.

Thank you for this. We had an uncovered case in our lib crud regarding composed keys and \Illuminate\Database\Eloquent\Collection::getDictionary