Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91941
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
MIME-Version: 1.0
References: <AF.A1.48999.49C0EE65@pb1.pair.com> <CACwt+JeYSGzH6caJHnMau1Rp5pPaV7dm4tXceprLAkr7xQUkug@mail.gmail.com>
 <51.DA.15440.52E44F65@pb1.pair.com>
In-Reply-To: <51.DA.15440.52E44F65@pb1.pair.com>
Date: Fri, 25 Mar 2016 11:38:09 +0000
Message-ID: <CACwt+Je3YqfEb73sPvTyEZTzTKCdEkE=wAOJa+4yYoDmKV6Hpw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11366346e78971052eddfffb
Subject: Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic
From: patrickallaert@php.net (Patrick ALLAERT)

--001a11366346e78971052eddfffb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le jeu. 24 mars 2016 =C3=A0 21:29, Andrea Faulds <ajf@ajf.me> a =C3=A9crit =
:

> 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 lin=
e
> 1
>      int(42)
>
>      $ sapi/cli/php -r 'var_dump(42 + null);'
>      int(42)
>
> > * You don't mention the <, >, <=3D and >=3D operators, is that intentio=
nal?
> > php > var_dump( 42 < "42 bananas" );
> > bool(false)
> > php > var_dump( 42 <=3D "42 bananas" );
> > bool(true)
> > php > var_dump( 42 > "42 bananas" );
> > bool(false)
> > php > var_dump( 42 >=3D "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.
>

I searched on the "<" / ">" chars, that's how I missed it. My bad!


> 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/


I understand and follow you on this.
Thanks for clearing everything out.

+1 :)

Patrick

--001a11366346e78971052eddfffb--