Re: [RFC] Safe Casting Functions
| From: | Marc Bennewitz | Date: | Fri, 24 Oct 2014 18:52:46 +0000 |
| Subject: | Re: [RFC] Safe Casting Functions | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78310@lists.php.net to get a copy of this message | ||
On 24.10.2014 20:13, Andrea Faulds wrote:
>> On 24 Oct 2014, at 19:06, Marc Bennewitz <php@mabe.berlin> wrote:
>>
>>
>> On 24.10.2014 01:53, Andrea Faulds wrote:
>>>> On 23 Oct 2014, at 20:50, Marc Bennewitz <php@mabe.berlin> wrote:
>>>>
>>>> You addresses data loss on convert float to int.
>>>> Do you also address data loss on int to float?
>>>>
>>>> |to_float(||9223372036854774784) -> pass |as it results in
>>>> 9223372036854774784
>>>> |to_float(|||9223372036854774785|) -> |fail as it results in
>>>> 9223372036854774784
>>> Floats aren’t expected to be precise, so I don’t see why this shouldn’t pass.
>>> It’s a loss of data, sure, but merely of precision, which is expected here. The reason I have
>>> to_int fail is because float overflow to int completely mangles your input.
>>> ... It’s a loss of data ...
>> And that is the point! If you don't care about loss of data we have more
>> than enough functions including default casting (float) operator to cast
>> to float.
> Floats are special, they are not expected to be precise. If we reject this, then perhaps we
> should also reject 0.1, because it can’t be precisely represented by a float?
It's a difference casting string to float or int to float.
Floats are often used to make sure an argument is a valid number but
this results in data loss incl. on internal functions.
take this simple example:
echo number_format(9223372036854774785);
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>