Hi Patrick,
Patrick ALLAERT wrote:
> Hi Andrea,
>
> Nice work.
>
> I'm globally +0.7 on it, there is however a few things that are unclear to
> me:
>
> * What happens with an empty string? Warning, notice or even nothing?
>
> * Would:
> 42 + "";
> produce the same thing than:
> 42 + null;
> currently, both are quiet, but both doesn't mean something.
"" is non-numeric, so (42 + "") produces a warning. This RFC doesn't
touch non-string values, however, so (42 + null) continues to produce no
error:
$ sapi/cli/php -r 'var_dump(42 + "");'
Warning: A non-numeric value encountered in Command line code on line 1
int(42)
$ sapi/cli/php -r 'var_dump(42 + null);'
int(42)
> * You don't mention the <, >, <= and >= operators, is that intentional?
> php > var_dump( 42 < "42 bananas" );
> bool(false)
> php > var_dump( 42 <= "42 bananas" );
> bool(true)
> php > var_dump( 42 > "42 bananas" );
> bool(false)
> php > var_dump( 42 >= "42 bananas" );
> bool(true)
The RFC does mention them in the "Unaffected PHP Functionality" section:
"It also does not impact the behaviour of type juggling for comparisons."
I can't entirely blame you for missing that, though.
So, those examples you provided will continue to not produce errors.
This is deliberate.
> It would be illogic, IMHO, to not take those operators into account and
> would introduce some inconsistencies, that is why I voted "No" although I'm
> generally ok with the whole idea.
I might like it if we change the behaviour of those operators, but I
don't think this is the RFC to do it in.
This RFC adds E_NOTICE and E_WARNING errors to certain operators that
take numbers as inputs and produce numbers as outputs. Arguably, strings
which are only partly a number, or not a number, are incorrect input for
these operators, or at the very least unlikely to be intentional on the
part of the programmer. Therefore, warning the programmer that the
inputs given were invalid is arguably helpful. I chose to produce
E_NOTICEs and E_WARNINGs because they are less likely to cause
backwards-compatibility issues than, for example, a TypeError, and this
is important given the release process RFC forbids us from breaking
compatibility in a minor release (like 7.1).
While I think my rationale above for adding warnings makes sense for
number operators, I don't think it works for the comparison ones. The
comparison operators all take two values which each can be of any type,
and there are no particular expectations about what their input should
be. Since non-well-formed numeric strings aren't invalid input, we don't
have the case to warn about them here.
What *is* a problem for the comparison operators is how they interpret
numeric strings, or even that they interpret them at all. A warning also
doesn't help here. So what would? Well, we could decide on some more
sensible interpretation of numeric strings. But that would mean that the
behaviour of the comparison operators would change, a significant
backwards-compatibility break, and a particularly bad one because it's
completely silent: there's no runtime warning that the behaviour has
changed, and no IDE or static analyser could warn you where your code
might have been affected. It's possible to make these kinds of changes
sometimes, but we must be very careful about it, and it shouldn't be
done in a minor release like 7.1. It would also be a controversial
change, so putting it in this RFC might doom the other changes it makes.
I hope this makes it clearer why I didn't touch the comparison operators
in this RFC. I think they're a separate, but related issue.
Thanks for asking.
--
Andrea Faulds
https://ajf.me/
