Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
Message-ID: <52C617A8.3060800@gmail.com>
Date: Fri, 03 Jan 2014 01:51:36 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <001801cf07e9$a07af1e0$e170d5a0$@tutteli.ch> <CAGa2bXaktXPADkfttuoYKE=XWH0962SAX-msiWDD+qbhNbhBbA@mail.gmail.com>
In-Reply-To: <CAGa2bXaktXPADkfttuoYKE=XWH0962SAX-msiWDD+qbhNbhBbA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] NAN and INF cast to int
From: rowan.collins@gmail.com (Rowan Collins)

On 02/01/2014 19:55, Yasuo Ohgaki wrote:
> I've added this to the RFC as an issue.
> https://wiki.php.net/rfc/comparison_inconsistency

The introduction on that RFC links to a rather confused bug report about 
min() and max() behaviour with mixed types. [1] The actual behaviour for 
comparisons between types is documented on the manual page for 
Comparison Operators [2], and is a largely separate issue to the 
behaviour of the actual conversions - it is not a question of how the 
values behave when converted, but which conversions are applied.

The current documentation for min() and max() is thoroughly unhelpful, 
implying special cases which don't exist, and missing behaviours that 
do. I submitted a patch on edit.php.net with revised examples and a 
clearer explanation and link to that page, but there seems to have been 
a glitch somewhere: the patches showed in the "Contributions are ready" 
reports for a while [3] but then seemingly disappeared without trace - I 
asked if anyone knew where they were, but nobody answered [4].

The non-commutativity of conversions does make this all very confusing 
(sorting arrays containing mixed types is actually unpredictable in some 
cases, and again the documentation is rather lacking), but is inevitable 
since such conversions may be "lossy" - e.g. (bool)42, (bool)43, and 
(bool)44 cannot possibly be distinct values. The only other option in 
many cases is simply to throw an error when such a comparison is 
attempted, and reject the entire computation.

Links:
[1] https://bugs.php.net/bug.php?id=53104
[2] http://php.net/manual/en/language.operators.comparison.php
[3] http://news.php.net/php.doc/969384748
[4] http://news.php.net/php.doc/969384775

Regards,

-- 
Rowan Collins
[IMSoP]