Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91930
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.154 cause and error)
To: Andrea Faulds <ajf@ajf.me>
References: <AF.A1.48999.49C0EE65@pb1.pair.com>
 <CACwt+JeYSGzH6caJHnMau1Rp5pPaV7dm4tXceprLAkr7xQUkug@mail.gmail.com>
 <51.DA.15440.52E44F65@pb1.pair.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <56F45B65.5090401@telia.com>
Date: Thu, 24 Mar 2016 22:25:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <51.DA.15440.52E44F65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] Warn about invalid strings in arithmetic
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2016-03-24 kl. 21:29, skrev Andrea Faulds:
> 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.
>
Came to think on a conversation with Sara G last year about introducing
the following operators, namely >==, <== & <==> working exactly like the
existing ones but without type juggling.

Maybe that would alleviate some of the issue here, giving new tools at
hand when writing new or updating existing code?

Regards //Björn