Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108842
MIME-Version: 1.0
References: <CAF+90c9EAHbYQ+2iUA9vw13wMUevjXRMajYE9TLCoqf2YXCfBw@mail.gmail.com>
In-Reply-To: <CAF+90c9EAHbYQ+2iUA9vw13wMUevjXRMajYE9TLCoqf2YXCfBw@mail.gmail.com>
Date: Wed, 4 Mar 2020 11:16:59 -0600
Message-ID: <CAESVnVq4P67UBZBJ6LUFkzcF6TqudgSrCgeipE4HOUWFPYiC0g@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e5e9ca05a00a979a"
Subject: Re: [PHP-DEV] Make sorting stable
From: pollita@php.net (Sara Golemon)

--000000000000e5e9ca05a00a979a
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov <nikita.ppv@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

--000000000000e5e9ca05a00a979a--