Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Mon, 31 Mar 2014 13:00:37 +0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.xdkwnbfdc9evq2@nikita-pc>
User-Agent: Opera Mail/12.16 (Win32)
Subject: usort callback should always return integer (not float)
From: inefedor@gmail.com ("Nikita Nefedov")

Hi,

I've just stumbled upon this limitation in sorting (compare) callbacks. Is  
there any
reason why we can't handle floats in this case?

I think it would be nice to be able to return float from the callback
because it's often happens that all it does is just `return
$a->someMethod() - $b->someMethod();` (where someMethod() returns float)  
or `return $a["something"] -
$b["something"];` and to make it work I need to write additional if  
statement. I think the reasoning could be complex behavior of doubles?  
Especially comparing doubles. But will we see any double-related pitfalls  
when all our code does with it is `return retval < 0 ? -1 : retval > 0 ? 1  
: 0;` (so essentially - compares them to zero)?


I made a PR [1] on github for 5.6 version. I think this change is pretty  
small and could go into 5.6 not breaking our release process rules? Though  
it WILL introduce some BC breaks for userland code that uses floats. But  
this code was already broken when it was relying on old behavior.

[1] https://github.com/php/php-src/pull/638