Sorry, reproduce code was incorrect. Correct code is below:

<?php
var_dump(array_unique(array(0,"","0")));
var_dump(array_unique(array("","0",0)));

Verified with 5.2, 5.3, HEAD.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Thank you so much. The snapshot returns same result to PHP 5.2.8 with reproduce code. Such as:

array(2) {
  [0]=>
  int(0)
  [1]=>
  string(0) ""
}
array(2) {
  [0]=>
  string(0) ""
  [1]=>
  string(1) "0"
}

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The slight BC breakage is negligible compared to the benefits of getting it to work properly.

This was not discussed, and thus no bogus thing.

OK, you think comparing elements as string is harmful, doesn't you?


Then, how about array_diff() or array_intersect()? They compare array elements with string representation. Isn't it harmful?

Hi, Andrei. Here's another terrible example.

<?php
$a=array("10","1az", "1e1");
var_dump(array_unique($a));
$b=array("1e1","10", "1az");
var_dump(array_unique($b));


The result is:


array(3) {
  [0]=>
  string(2) "10"
  [1]=>
  string(3) "1az"
  [2]=>
  string(3) "1e1"
}
array(2) {
  [0]=>
  string(3) "1e1"
  [2]=>
  string(3) "1az"
}


The array $a and $b have same 3 elements with different ordering. Although, two array_unique() returns different result.

First array_unique() returns 3 elements in spite of the fact that "10" equals "1e1" with ==.

In fact, the two arrays are both sorted about SORT_REGULAR. Because "10" < "1az" , "1az" < "1e1" and "1e1"=="10". Sorting with SORT_REGULAR is not stable, and unique element is not always in neighbor.

This behavior is not obvious for almost all PHP programmer. You should explain the detail of your function in reference manual.

Andrei, you must add a note about the behavioral change.

See also bug #48115 (yes, WTF?!)

Hi Guys,

We are facing the same BC problem with array_unique.
Consider following test script:

<?php

$array = array( '400.00', '400' );

// Here 400 value exists
// array(2) { [0]=> string(6) "400.00" [1]=> string(3) "400" }
var_dump($array);

$arrayTest1 = array_unique( $array );

// Here 400 value is missing
// array(1) { [0]=> string(6) "400.00" }
// Prior verstion 5.2.9 this always returned array(2) { [0]=> 
string(6) "400.00" [1]=> string(3) "400" }
var_dump($arrayTest1);

$arrayTest2 = array_unique( $array, SORT_STRING );

// Here 400 value exists
// array(2) { [0]=> string(6) "400.00" [1]=> string(3) "400" }
var_dump( $arrayTest2 );

?>

This is definitely BC break in 5.2.9 as comparing '400.000' and '400' 
in array_unique in PHP versions prior 5.2.9 returned both values. In 
PHP 5.2.9 it return '400.000'.

Andrei, can you please have a look at this? This is BC break for quite a few applications.

The change is reverted in next releases (all branches).