Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

[Marc Bennewitz]

Hi Jakub,

On 16.10.23 00:17, Jakub Zelenka wrote:

Your JSON example is a bit unrelated because if you care about your
types your should have used JSON_RESERVE_ZERO_FRACTION in the first
place else you should not care about int vs float at all.

The thing is that JSON might be encoded by another application that doesn't
care about types that much. In fact in JSON there is no difference between
2.0 and 2. So this is quite possible situation IMHO.

That's obviously true but on the same time you should validate and filter your input data. And if you expect a floating point number you need to handle that case explicitly before processing and not leave it to an implicit transformation just hoping everything will be fine.

It's true that passing/returning int to/from a function expecting float
will cast but currently with these rounding functions it's a different
deal as they expect an `int|float` instead of just `float`. So it's not
cast on passing the argument but the functions itself are casting.

Well internally yeah but effectively it is a cast on the return type. What
I meant is that this wont help everywhere when it's passed to function
expecting just float unless it is changed by user to accept int|float.

Where another set of functions would avoid the BC break it also would be

against having PHP as a loosely typed languageputting the burden to
everyone caring. I already see hundreds of `is_int($v) ? round_int($v) :
round($v)` everywhere around.

But for me it's sort of an edge as I would think it is not that usual
rounding values that are greater than 2^53. I think it would be good to
note in the RFC what other language do about this issue. I quickly checked
Go and it seems to only have float64 rounding (Math.Round). Rust seems to
also round just f64.

At least python's build-in round function keeps the input type, as long as ndigits is given, else it even goes further and returns an int.

I'm starting to feel that the problem is that the input type is defined as
int|float. I think we should just correct it to float.

With the current behavior ... yes, but this does not make these functions any better. Sure, I'm trying to improve a case for that does not happen often, but it happens at least for me on working with representing statistical data where using GMP/bcmath ... does not outweigh it's overhead. On the same time the results can be improved without adding overhead.

Regards

Jakub

Best,
Marc

OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature