This is the expected behaviour, as SORT_REGULAR uses == under the hood.

From the sort() page (which has a better description then array_unique())

SORT_REGULAR - compare items normally; the details are described in the comparison operators section

Therefore, changing this to a feature request, by possibly introducing a new flag.

I just wonder what the behaviour should be in case someone decides to use this new flag in sorting and the values aren't comparable because they are of different types. An exception maybe? But then again that's probably a bit strange because array_unique wouldn't have this issue.

Should the default behaviour of array_uniq depend on declare(strict_types = 1)?

Should the default behaviour of array_uniq depend on declare(strict_types = 1)?

strict_types is about function arguments at call time. It shouldn't control runtime behavior this way.

I just wonder what the behaviour should be in case someone decides to use this new flag in sorting and the values aren't comparable because they are of different types. An exception maybe? But then again that's probably a bit strange because array_unique wouldn't have this issue.

New sorting method have to sort by type first, because array_unique is relaying on consistent comparisons for optimization, so if used in sort it would sort by types then values - probably useless but would work fine.

Thus new method would look something like this:

function cmp_strict(mixed $a, mixed $b): int
{
	if ($a === $b) return 0;

	$typeA = gettype($a);
	$typeB = gettype($b);
	if ($typeA === $typeB) {
		// abstract function to compare values without type juggling
		return cmp_values_strict($a, $b);
	} else {
		return $typeA <=> $typeB;
	}
}

Therefore, changing this to a feature request, by possibly introducing a new flag.

As with sort functions, array_unique could allow use of custom comparison function to cover more complex cases (e.g. when multiple values have same meaning), though flag would be more convenient in almost every case.

Thanks for pointing that out, it looks indeed like a logical comparison function. I can spend some time this week to try and implement a PoC.

Err wait... The example code of a comparator posted here wouldn't work too... For example cmp_strict(0, '0') would cause the branch with the spaceship operator to be executed, which results in a return value of 0. This means that array_unique would remove on of the two, which is the exact problem in this issue report.

The main problem is that there seems to be no total order relation on elements of all sorts of different type combinations. For example: is '0'<0, or is 0<'0'? If both answers are yes then we have an inconsistency in sorting. If both answers are no then they must be equal, which causes OP's problem. In other cases the ordering is arbitrary.

So although this issue proposes to add a new flag, we cannot use that flag in a consistent way for sorting. The flag would be unique to array_unique and must be handled in a special way AFAICT. Or we have to come up with an ordering scheme that works for all type combinations.

For example cmp_strict(0, '0') would cause the branch with the spaceship operator to be executed, which results in a return value of 0.

@nielsdos Branch with spaceship operator is only comparing types, which are always string and always starting with letter, so it's safe comparison. https://3v4l.org/jnLno

For example: is '0'<0, or is 0<'0'?

"integer" < "string" thus 0<'0'.

So although this issue proposes to add a new flag, we cannot use that flag in a consistent way for sorting.

Sorting by type first is consistent way of sorting, not sure if should be allowed in sort, but won't hurt anything.

Or we have to come up with an ordering scheme that works for all type combinations.

Comparing types first should be faster for mixed arrays, which is ideal for array_unique.

This is a bit closer to proper implementation: https://3v4l.org/2oRQt

@KapitanOczywisty Sorry, my bad, I misread the code. So the solution here is the "arbitrary order" option I listed which seems not super arbitrary after all since it seems to be consistent with zend_compare. I'll try this tomorrow.

This is essentially the same as #9775, so I'm closing this as a duplicate. Please continue discussion there if you have anything to add.