Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111014 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58177 invoked from network); 15 Jul 2020 09:57:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Jul 2020 09:57:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C8731180506 for ; Wed, 15 Jul 2020 01:49:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from srv015.mail.ichtushosting.com (srv015.mail.ichtushosting.com [159.69.182.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 15 Jul 2020 01:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stitcher.io ; s=default; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CntWuwS19up8kSmMmYoA8BkhCCd+tuwOouMnrahg+4Q=; b=qJtvXoqa0U7d+Z3zILCWs9vbOS ShTHjx1YDNUteabkmKcEhQolDWz8OqxROgz7Aar4T3gfTc+KcjKcwoOJw1FbOtu+JanPEUSul15uB qdnmj0aiLEhcHlrHJ3mF/UWb1RfIge4Yx5Uo5C94YDRsEHU2YkvP6udd0cyyRBDcunsnFcFqzOXGl JrJOhNouud+kAMxflEQH9uFlDtGi4sT/mL/6Q9FIN8uLMthVK4xkcI6MIb3XonqLelgLgCRqjCitU d8l1gzaG6oOqEzSNL+hKysklUnhHV1BZC9JEpmObYpqENEi0v8D8Ve9p1/VZZcSY8OM/GH+jskBKc Vi4WqlVQ==; Received: from srv021.web.ichtushosting.com ([78.47.76.72]) by srv015.mail.ichtushosting.com stage1 with esmtp (Exim MailCleaner) id 1jvd6f-0006Xy-10 from ; Wed, 15 Jul 2020 10:49:37 +0200 Received: from ptr-fq9pjpgvj3gr8k7rx9d.18120a2.ip6.access.telenet.be (ptr-fq9pjpgvj3gr8k7rx9d.18120a2.ip6.access.telenet.be [IPv6:2a02:1812:c3c:3a00:3552:23b1:3db1:5821]) (Authenticated sender: brendt@stitcher.io) by srv021.web.ichtushosting.com (Postfix) with ESMTPSA id D53F820D20; Wed, 15 Jul 2020 10:49:34 +0200 (CEST) Message-ID: <44637D3E-5F0B-4AEF-A154-21C8FF20ED91@stitcher.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_EF7E6B34-14CE-4FA4-886B-9A9E17FE8A9A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Jul 2020 10:49:33 +0200 In-Reply-To: Cc: PHP internals To: Nikita Popov References: <529e7a72-8bd7-b4f4-a987-0e88d37e47b5@telia.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-MailCleaner-TrustedIPs: Ok Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons From: brendt@stitcher.io (Brent Roose) --Apple-Mail=_EF7E6B34-14CE-4FA4-886B-9A9E17FE8A9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. Kind regards Brent > On 15 Jul 2020, at 10:28, Nikita Popov wrote: >=20 > On Tue, Jul 14, 2020 at 11:47 PM Bj=C3=B6rn Larsson = > > wrote: >=20 >> Den 2020-07-14 kl. 15:48, skrev Nikita Popov: >>> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov >> wrote: >>>=20 >>>> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov >> wrote: >>>>=20 >>>>> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski = wrote: >>>>>=20 >>>>>>=20 >>>>>> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov = >>>>>> wrote: >>>>>>=20 >>>>>>> Hi internals, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>> https://wiki.php.net/rfc/string_to_number_comparison >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>> I generally like the direction and think we should seriously = consider >> it. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Zeev >>>>>>=20 >>>>> 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 >>>>>=20 >>>>> 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.) >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 ^^ >>>>>=20 >>>>> Regards, >>>>> Nikita >>>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Now would be the time to decide whether or not we want to pursue = this >>>> change for PHP 8. >>>>=20 >>> And then there was silence... >>>=20 >>> I think I'll just put this up for vote on Friday, and we'll see what >> people >>> think :) >>>=20 >>> Nikita >>=20 >> Seems like a very good idea!! Especially in conjunction with the RFC: >> - https://wiki.php.net/rfc/saner-numeric-strings >>=20 >> Btw, in the RFC there is a reference to the "Trailing whitespace in = numeric >> strings" RFC. Update to reference "Saner numeric strings" RFC = instead? >>=20 >=20 > Thanks, I've updated the link to point to the new proposal! >=20 > Nikita --Apple-Mail=_EF7E6B34-14CE-4FA4-886B-9A9E17FE8A9A--