Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96605
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
To: internals@lists.php.net
References: <e85362ca-db50-75a5-343a-e6f4818562b9@mabe.berlin>
 <CANUQDCiLG0XX7d5_8GJWUfi8P0VGvSLhrg3B43faPuMjrvXBPQ@mail.gmail.com>
 <2cab4219-5128-7493-c604-5772534743ea@mabe.berlin>
 <2A.9D.28528.43F0E085@pb1.pair.com>
Message-ID: <3b5cea00-2d80-8f96-e797-abb3ce409e6c@mabe.berlin>
Date: Mon, 24 Oct 2016 22:25:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <2A.9D.28528.43F0E085@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] strtod and NaN vs. zero
From: dev@mabe.berlin (Marc Bennewitz)

Hi Andrea,

Am 24.10.2016 um 15:40 schrieb Andrea Faulds:
> Hi,
>
> Marc Bennewitz wrote:
>>
>> But I'm still curious why casting any non numeric string results in the
>> valid number float(0) where there is a special value in floating point
>> numbers declared to represent not a number values.
>
> Because that's what C's strtod() does, and it's also what (int) does
> (because that's what C's strtol()) does.
>
> There'd be an argument for using NaN, sure, but it wouldn't be
> consistent with the rest of the language. Generally, PHP assumes that a
> string with no leading digits has the number value of zero. This is true
> not only in (int) and (float) casts, but also in generic number coercion
> operations, like with +, -, *, / and **. To change the behaviour of
> (float) here would be to introduce a new inconsistency to PHP. If we go
> for NaN everywhere, then we introduce a different problem: (int) should
> return an integer, and the generic number coercions prefer giving you an
> integer rather than a float if appropriate. Producing a NaN here would
> mean you'd now get an int rather than a float, and would cause a
> cascading change in operation result types which could lead to
> previously working code now throwing lots of E_WARNINGs or TypeErrors
> (NaN is not accepted for integer type declarations in weak mode, and all
> floats are not accepted for integer type declarations in strict mode).

Thanks for your explanation.

It's totally true that on casting non numeric string to integer will 
result in 0 but that's a different type even if it's also a numeric type.

 From my understanding PHP tries to cast from one type to another by 
loosing as less information as possible. In this case I see a non 
numeric string that gets casted to a float will loose exactly this 
information that it's "Not a Number" where it would be possible to keep 
this information. On casting this to int there is of course no 
possibility to keep it but I don't see where it's inconsistent as it's a 
different type used for different use-cases.

Having mathematical operations with non numeric strings should result in 
the same behavior as NaN will result in NaN which makes sense and I 
don't see where it will throw lots on WARNINGS or TypeErrors as it's 
still a float. Since PHP-7.0 there was a WARNING introduced "A 
non-numeric value encountered" which is nice but the result is still a 
valid float where "Not a Number" would be more logical. That's of course 
my personal opinion.

Of course changing this would introduce a BC break and therefore should 
be reviewed safely. But the bug #73329 shows that there is not much 
attention as it stayed for some versions.

This mail is not an RFC not even a proposal it's just mail to get an 
answered why (Thanks again) and to see how others think about.

>
> Thanks.
>

Thanks
Marc