Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86684
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.174 as permitted sender)
Message-ID: <557F4149.8040705@gmail.com>
Date: Mon, 15 Jun 2015 14:19:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, 
 PHP Internals <internals@lists.php.net>
References: <CA+9eiLsTzAHZ=r3vPFWbL_ApQb4q-6MPQerJ7ek403KECz1DEg@mail.gmail.com> <BLU436-SMTP699F008CADD26FD35FF352E2B80@phx.gbl> <06AFCBA8-CEB0-4AC1-BB72-ACA6213F4334@gmail.com>
In-Reply-To: <06AFCBA8-CEB0-4AC1-BB72-ACA6213F4334@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Spaceship and NaNs
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

>> Just because other comparison ops already return a bool, we can return
>> bool(false) there.

But we can not return bool from operator that is declared as returning
int, and adding extra type would make this operator essentially useless,
as it is meant to be a concise way of comparing two things, and if after
that you need to write a parser to figure out what it returned, it's
much easier to just go back to basic comparison operators.

Since not everything among PHP values is well-ordered, there would be
sets of values for which comparison does not make intuitive sense - i.e.
both < and > are false, etc. In this case, there is no intuitive value
to return, but there should be a well-defined one to return, and we have
a pretty good definition here I think:

https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#relational-operators
-- 
Stas Malyshev
smalyshev@gmail.com