Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104521
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 13:06:05 +0000
Message-ID: <CALKiJKoSbrq=GYDY1Rsch2pbDft7piw1xkKXs97xYaA8DrytQw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f447ad0582cbb8be"
Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000f447ad0582cbb8be
Content-Type: text/plain; charset="UTF-8"

On Tue, 26 Feb 2019 at 12:27, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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
>


Hi Nikita,

Thanks for tackling this; I think if we can improve this, we'll be
answering a lot of language critics (I'm sure they'll find something else
to complain about, but that's life!).

However, I'm concerned that it doesn't go far enough, when you say that the
following will still return true:

0 == "0e214987142012"
"0" == "0e214987142012"

I think the cases where this is useful are vastly outweighed by the cases
where it's completely unexpected, and potentially dangerous (e.g. in a hash
comparison). If this is not fixed, the "dogma to always avoid non-strict
comparisons" you refer to will remain.

If I understand it right, this arises from the fact that "0e214987142012"
is considered a "well-formed numeric string", which is cast to int(0) or
float(0). Is it feasible to also narrow this definition as part of the same
change?

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000f447ad0582cbb8be--