Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104531
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=xzs/QmPrUpjElf2rgkSqN+lxkWEWQGEPMmYMzZnKW8XZ45R8zT9lH6IKnsn4S1
	Ia8S6iahVJsdpicEIU0rDJyHq9jXyubXbyK73GfcaqQ4GzLJG4y3m6IggLbcvcMA
	/aNGhhz4upKPfv+Ke/iIQIvoXxYp3msk22/k3XSOvPjGo=;
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: Wed, 27 Feb 2019 11:23:34 +0200
Message-ID: <CAJHtzny=SX_ojsohApAY8Xe7c_EMAKGbNe110QQVh7i5yGFm_A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000002be470582dcbb86"
Subject: Re: [PHP-DEV] [RFC] Saner string to number comparisons
From: zeev@php.net (Zeev Suraski)

--00000000000002be470582dcbb86
Content-Type: text/plain; charset="UTF-8"

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 == 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.
>

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

--00000000000002be470582dcbb86--