Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104520
MIME-Version: 1.0
References: <CAF+90c821boRO6YsO0SH0JbDb8E8eTHfEK=e4Y5_z9P7+OOnUg@mail.gmail.com>
In-Reply-To: <CAF+90c821boRO6YsO0SH0JbDb8E8eTHfEK=e4Y5_z9P7+OOnUg@mail.gmail.com>
Date: Tue, 26 Feb 2019 14:04:44 +0100
Message-ID: <CAFPFaMJSBoHHPu_e_Jw1xLt=1MrQKRE13RvVpAzp7FsP2EAbbg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000039166d0582cbb4f4"
Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons
From: george.banyard@gmail.com ("G. P. B.")

--00000000000039166d0582cbb4f4
Content-Type: text/plain; charset="UTF-8"

On Tue, 26 Feb 2019 at 13:27, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I think it is well known that == in PHP is a pretty big footgun. It doesn't
> have to be. I think that type juggling comparisons in a language like PHP
> have some merit, it's just that the particular semantics of == in PHP make
> it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
> returns true.
>
> I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> and other non-strict comparisons, when used between a number and a string:
>
> https://wiki.php.net/rfc/string_to_number_comparison
>
> The tl;dr is that if you compare a number and a numeric string, they'll be
> compared as numbers. Otherwise, the number is converted into a string and
> they'll be compared as strings.
>
> This is a very significant change -- not so much because the actual BC
> breakage is expected to be particularly large, but because it is a silent
> change in core language semantics, which makes it hard to determine whether
> or not code is affected by the change. There are things we can do about
> this, for example the RFC suggests that we might want to have a transition
> mode where we perform the comparison using both the old and the new
> semantics and warn if the result differs.
>
> I think we should give serious consideration to making such a change. I'd
> be interested to hear whether other people think this is worthwhile, and
> how we could go about doing it, while minimizing breakage.
>
> Regards,
> Nikita
>

I am in favor of this change however I do think having the Trailing
Whitespaces numerics RFC
would be better for this change as I do agree with you that IMHO 42 == "42
" should return true.
I'm also not sure if you maybe should point this out sooner but as it is
currently seems fine to me.

However small nitpick on your precision section

$float = 1.75;
 ini_set <http://www.php.net/ini_set>('precision', 14); //
Defaultvar_dump <http://www.php.net/var_dump>($float < "1.75abc");//
Behaves likevar_dump <http://www.php.net/var_dump>("1.75" <
"1.75abc"); // true

is wrong because var_dump($float < "1.75abc"); returns false:
https://3v4l.org/G56Vj
I think you meant to use the <= comparison operator maybe?

Also the NAN behavior is a bit surprising (to me atleast) but it does
follow the IEEE-754
However I don't really understand why it always returns 1 with the TIE
operator.

And finally as to how to do the transition I don't really have a strong
opinion about it.
An INI setting seems like this behavior is going to be supported for a long
time.
But it doesn't seem like its possible to throw deprecation notices to alert
of this change.

Best regards

George P. Banyard

--00000000000039166d0582cbb4f4--