Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86679
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <BLU436-SMTP699F008CADD26FD35FF352E2B80@phx.gbl>
References: <CA+9eiLsTzAHZ=r3vPFWbL_ApQb4q-6MPQerJ7ek403KECz1DEg@mail.gmail.com> <BLU436-SMTP699F008CADD26FD35FF352E2B80@phx.gbl>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Mon, 15 Jun 2015 21:45:53 +0100
To: PHP Internals <internals@lists.php.net>
Message-ID: <06AFCBA8-CEB0-4AC1-BB72-ACA6213F4334@gmail.com>
Subject: Re: [PHP-DEV] Spaceship and NaNs
From: rowan.collins@gmail.com (Rowan Collins)

On 15 June 2015 20:55:04 BST, Bob Weinand <bobwei9@hotmail.com> wrote:
>As far as I know, we made it that way in order to enforce an int return
>type all the time.
>int(-1) is indeed the sensible value for this. (Mainly int(0) does not
>work because it'd mean equality and so we're left with int(-1) and
>int(1).)
>
>Just because other comparison ops already return a bool, we can return
>bool(false) there.

This makes a lot of sense. If it returned false, that would just be cast to 0 in most situations, implying that NaN is equal to everything (rather than nothing). In other situations, it would simply lead to an error. The operator would lose much of its value if it had to be surrounded with error traps and caveats because it didn't reliably return an integer.

Regards,
-- 
Rowan Collins
[IMSoP]