Found something else today http://3v4l.org/mO48q
echo [1, 2, 3] <=> []; // 1 but it gives 3 On Mon, Apr 20, 2015 at 7:29 PM, Pasindu De Silva <ppasin...@gmail.com> wrote: > Hi > Found this while trying to do the documentation, Thought the same that it > was a RFC mistake, > therefore didn't put any examples. Will do the necessary documentation if > this is the case. > > +1 > Pasindu > > > On Mon, Apr 20, 2015 at 7:13 PM, Christoph Becker <cmbecke...@gmx.de> > wrote: > >> Hi! >> >> Stanislav Malyshev wrote: >> >> > Ahh, I see. I think it's the mistake in the RFC. [...] >> >> Then it is probably best to fix the RFC. :) >> >> > I'm not a big fan of throwing too many notices. They are usually not >> > very helpful an din this case it would be not easy to distinguish >> > between intentional and unintentional use. >> >> <snip> >> >> > $a > $b being false is an artifact of how ">" works in the engine - $a > >> > $b is essentially ($b < $a). Since in this case both $a > $b and $b > >> > $a, the result of ($b < $a) is false. That's what you get when you >> > compare non-well-ordered things... >> >> I get your point. I suggest to amend the documentation[1] to make it >> clear that comparing non-well-ordered values results in undefined >> behavior (it might be best to treat the return value 1 in this case as >> implementation specific). >> >> [1] <http://php.net/manual/en/language.operators.comparison.php> >> >> -- >> Christoph M. Becker >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > > *Pasindu De Silva**ppasin...@gmail.com <ppasin...@gmail.com>* > -- *Pasindu De Silva**ppasin...@gmail.com <ppasin...@gmail.com>*
