Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111015
MIME-Version: 1.0
References: <CAF+90c821boRO6YsO0SH0JbDb8E8eTHfEK=e4Y5_z9P7+OOnUg@mail.gmail.com>
 <CAJHtzny=SX_ojsohApAY8Xe7c_EMAKGbNe110QQVh7i5yGFm_A@mail.gmail.com>
 <CAF+90c-6iEBPjWuzA6=bAr=85N=JNV0+GqL3_maak3yqVP-e=Q@mail.gmail.com>
 <CAF+90c9DxVz2Ro3yJ0-jDuPXg5Ffe3F9ERE8wHt=7ERjOm01Sw@mail.gmail.com>
 <CAF+90c_vyLakwP=1QrWUJh2rwJtcsMtPSYzyqxqOeXecGYcQTg@mail.gmail.com>
 <529e7a72-8bd7-b4f4-a987-0e88d37e47b5@telia.com> <CAF+90c_sxBHXv6Sk1eaY-2bJG24aefDE2oLEeDS8fuuFH8PoZA@mail.gmail.com>
 <44637D3E-5F0B-4AEF-A154-21C8FF20ED91@stitcher.io>
In-Reply-To: <44637D3E-5F0B-4AEF-A154-21C8FF20ED91@stitcher.io>
Date: Wed, 15 Jul 2020 10:53:46 +0200
Message-ID: <CAF+90c_Hv+xR3TTsHJU+KPosBQ3SjuTSaRf6vdaYYvTN7R9RZQ@mail.gmail.com>
To: Brent Roose <brendt@stitcher.io>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c7d77905aa771014"
Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c7d77905aa771014
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 15, 2020 at 10:49 AM Brent Roose <brendt@stitcher.io> wrote:

> Hi Nikita
>
> Is the ini setting available in current 7.4 builds? Is it documented
> somewhere? I'd like to test this change in some of our projects.
>

We did not introduce an ini setting in PHP 7.4, I only used it for my own
experiments. The implementation is available at
https://github.com/php/php-src/pull/3917. I could rebase that to current
7.4 if that would be useful.

Nikita

> On 15 Jul 2020, at 10:28, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Tue, Jul 14, 2020 at 11:47 PM Bj=C3=B6rn Larsson <bjorn.x.larsson@teli=
a.com>
> wrote:
>
> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>
> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov <nikita.ppv@gmail.com>
>
> wrote:
>
>
> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov <nikita.ppv@gmail.com>
>
> wrote:
>
>
> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski <zeev@php.net> wrote:
>
>
> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
> Hi internals,
>
> I think it is well known that =3D=3D 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 =3D=3D in PHP
> make
> it so dangerous. The biggest WTF factor is probably that 0 =3D=3D
>
> "foobar"
>
> returns true.
>
> I'd like to bring forward an RFC for PHP 8 to change the semantics
>
> of =3D=3D
>
> 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.
>
> I generally like the direction and think we should seriously consider
>
> it.
>
>
> I think that before we make any decisions on this, or even dive too
>
> deep
>
> into the discussion - we actually need to implement this behavior,
> including the proposed INI setting you mentioned we might add in 7.4
>
> - and
>
> see what happens in some real world apps, at least in terms of
>
> potential
>
> danger (as you say, figuring out whether there's actual breakage would
> require a full audit of every potentially problematic sample.
>
> Ultimately,
>
> I think there's no question that if we were to start from scratch,
>
> we'd be
>
> going for something along these lines.  But since we're not starting
>
> from
>
> scratch - scoping the level of breakage is key here.
>
> Zeev
>
> Totally agree that assessing the amount of breakage in real code is key
> here. I have now implemented a warning for PHP 7.4 (for now
>
> unconditional,
>
> no ini setting) that is thrown whenever the result of a comparison is
>
> going
>
> to change under the currently proposed rules:
> https://github.com/php/php-src/pull/3917
>
> I've done a few initial tests by running this against the Laravel,
> Symfony and pear-core. The warning was thrown 2 times for Laravel, 1
>
> times
>
> for Symfony and 2 times for pear-core. (See PR for the results.)
>
> Both of the warnings in pear-core pointed to implementation bugs. The
> Symfony warning was due to trailing whitespace not being allowed in
>
> numeric
>
> strings (something we should definitely change). One of the Laravel
> warnings is ultimately a false-positive (does not change behavior),
>
> though
>
> code could be improved to avoid it. I wasn't able to tell whether the
>
> other
>
> one is problematic, as it affects sorting order.
>
> I have to say that this is a lot less warnings than I expected. Makes
>
> me
>
> wonder if I didn't make an implementation mistake ^^
>
> Regards,
> Nikita
>
> As we're moving closer to PHP 8 feature freeze, I want to give this RFC
>
> a
>
> bump. I've updated the text to account for some changes that have
>
> happened
>
> in the meantime, such as the removal of locale-sensitivity for float to
> string conversions.
>
> It's been quite a while since we discussed this last, and back then the
> discussion was fairly positive. Some experiments with a warning mode
>
> also
>
> showed that the impact, at least in framework/library code, appears to
>
> be
>
> fairly low in practice, contrary to what one might intuitively expect.
>
> Now would be the time to decide whether or not we want to pursue this
> change for PHP 8.
>
> And then there was silence...
>
> I think I'll just put this up for vote on Friday, and we'll see what
>
> people
>
> think :)
>
> Nikita
>
>
> Seems like a very good idea!! Especially in conjunction with the RFC:
> - https://wiki.php.net/rfc/saner-numeric-strings
>
> Btw, in the RFC there is a reference to the "Trailing whitespace in numer=
ic
> strings" RFC. Update to reference "Saner numeric strings" RFC instead?
>
>
> Thanks, I've updated the link to point to the new proposal!
>
> Nikita
>
>
>

--000000000000c7d77905aa771014--