On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov <nikita....@gmail.com> wrote:
> The only issue I ran into is that this change has a negative impact on code
> using illegal comparison callbacks like this:
>
> usort($array, function($a, $b) {
> return $a > $b;
> });
>
> Let's define what "negative impact" means in this regard. Is it that one
still winds up with an essentially sorted array, but hitherto "stable
appering" output is now stable in a different way? Or is the result
actually just NOT sorted in a way that a reasonable user would consider
correct (e.g. 5 sorted before "3")?
If it's the former, then I'm generally disinclined to be concerned about
the breakage. We never made a promise about comparison equality
resolution, so moving to making a promise about it isn't violating anything.
> This kind of incorrect code will break under the proposed implementation,
> because we will now compare by original position if the comparison function
> reports equality. Because the comparator reports equality inconsistently
> (it says that $a == $b, but $b != $a), the sort results are also
> inconsistent.
>
> I read this user-space comparator as saying that values are never equal.
Sometimes $a > $b and $b > $a are both true, which is terrible. But if
they never report equality, then position sorting should never come into
play.
> What do people think about this? Is there interest in making sorting
> stable? Is it okay to break code using illegal comparison callbacks?
>
> Generally +1, just curious about what breaks and how.
-Sara
