Yes that would be nice, if it's not too much of a hassle. I'm only able to
test this in one or two large Laravel projects, so it would still be a
Done! https://github.com/php/php-src/pull/3917 is now based on current 7.4
HEAD. Note that it just unconditionally throws a warning, without a way to
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.
On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson <[email protected]
Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov [email protected]
On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov [email protected]
On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov [email protected]
I think it is well known that == in PHP is a pretty big footgun. It
have to be. I think that type juggling comparisons in a language like
have some merit, it's just that the particular semantics of == in PHP
it so dangerous. The biggest WTF factor is probably that 0 ==
I'd like to bring forward an RFC for PHP 8 to change the semantics
and other non-strict comparisons, when used between a number and a
The tl;dr is that if you compare a number and a numeric string,
compared as numbers. Otherwise, the number is converted into a string
they'll be compared as strings.
This is a very significant change -- not so much because the actual
breakage is expected to be particularly large, but because it is a
change in core language semantics, which makes it hard to determine
or not code is affected by the change. There are things we can do
this, for example the RFC suggests that we might want to have a
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.
be interested to hear whether other people think this is worthwhile,
how we could go about doing it, while minimizing breakage.
I generally like the direction and think we should seriously consider
I think that before we make any decisions on this, or even dive too
into the discussion - we actually need to implement this behavior,
including the proposed INI setting you mentioned we might add in 7.4
see what happens in some real world apps, at least in terms of
danger (as you say, figuring out whether there's actual breakage would
require a full audit of every potentially problematic sample.
I think there's no question that if we were to start from scratch,
going for something along these lines. But since we're not starting
scratch - scoping the level of breakage is key here.
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
no ini setting) that is thrown whenever the result of a comparison is
to change under the currently proposed rules:
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
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
strings (something we should definitely change). One of the Laravel
warnings is ultimately a false-positive (does not change behavior),
code could be improved to avoid it. I wasn't able to tell whether the
one is problematic, as it affects sorting order.
I have to say that this is a lot less warnings than I expected. Makes
wonder if I didn't make an implementation mistake ^^
As we're moving closer to PHP 8 feature freeze, I want to give this RFC
bump. I've updated the text to account for some changes that have
in the meantime, such as the removal of locale-sensitivity for float to
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
showed that the impact, at least in framework/library code, appears to
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
Seems like a very good idea!! Especially in conjunction with the RFC:
Btw, in the RFC there is a reference to the "Trailing whitespace in
strings" RFC. Update to reference "Saner numeric strings" RFC instead?
Thanks, I've updated the link to point to the new proposal!