[PHP-DEV] [RFC] [Discussion] [VOTE] Rounding Integers as int

Mailing Lists php.internals
1

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
https://wiki.php.net/rfc/integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

2

Hi

On 3/17/24 13:23, Marc Bennewitz wrote:

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Please also update the Status within the RFC itself and move it to the correct section in the RFC overview at: PHP: rfc

Best regards
Tim Düsterhus

3

On 17.03.24 14:10, Tim Düsterhus wrote:

Hi

On 3/17/24 13:23, Marc Bennewitz wrote:

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Please also update the Status within the RFC itself and move it to the correct section in the RFC overview at: PHP: rfc

Thank you for the reminder. Updated the status and moved in correct section now.

Best regards
Tim Düsterhus

4

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

Hey Marc,

I've voted no; it should be just changed without any force_float parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly cast via (float).

The effective BC break of that would be quite small if some things which return float today now would return int. I cannot imagine many cases where this would actually be unwanted. And as said, explicit (float) casts are always possible.

I also dislike force_float, as it cannot just be added to a function in any code which shall be backwards compatible to 8.3 and older. It would just emit Uncaught Error: Unknown named parameter $force_float.

Bob

5

Hi,

IMHO, the more meaningful cases of the RFC are missing :

round(float, precision: >= 0): int|float // only cast to float for int overflow
ceil(float): int|float // only cast to float for int overflow
floor(float): int|float // only cast to float for int overflow

Calling ceil or floor on integer is meaningless, because it will return the same value.
The RFC should be “Prefer int as return value when possible”.

Le dim. 17 mars 2024 à 15:00, Bob Weinand <bobwei9@hotmail.com> a écrit :

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the “Rounding Integers as int” RFC:
https://wiki.php.net/rfc/integer-rounding

Do to Easter weekend the vote will run for two weeks and two days
until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

Hey Marc,

I’ve voted no; it should be just changed without any force_float
parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly
cast via (float).

The effective BC break of that would be quite small if some things which
return float today now would return int. I cannot imagine many cases
where this would actually be unwanted. And as said, explicit (float)
casts are always possible.

I also dislike force_float, as it cannot just be added to a function in
any code which shall be backwards compatible to 8.3 and older. It would
just emit Uncaught Error: Unknown named parameter $force_float.

Bob

6

Hi Bob,

On 17.03.24 14:59, Bob Weinand wrote:

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

Hey Marc,

I've voted no; it should be just changed without any force_float parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly cast via (float).

The effective BC break of that would be quite small if some things which return float today now would return int. I cannot imagine many cases where this would actually be unwanted. And as said, explicit (float) casts are always possible.

I also dislike force_float, as it cannot just be added to a function in any code which shall be backwards compatible to 8.3 and older. It would just emit Uncaught Error: Unknown named parameter $force_float.

Changing the return type from float to int is a non trivial quite hard to find behavior change.

Imaging code like this:

$x = 800;
$y = 800;
round($x/$y) === 1.0;

This will return false instead of true especially because we teach users to use strict comparison.
Such behavior change should be done in a major version.

With the additional parameter it's possible to opt-in into the new behavior already in 8.4 while in PHP 9.0 the default behavior will change but previously opted in code does not need to get touched again.

Just changing the behavior means waiting for PHP 9.0 without a way to opt-in in 8.4 already. If you are not interested in opting in in 8.4 already you can just ignore the additional argument as this will be the default in 9.0.

To mimic the previous behavior in a fully BC way it's as simple as explicitly casting the value to float.

Bob

Regards,
Marc

7

Hi Vincent,

···

On 17.03.24 22:59, Vincent Langlet wrote:

Hi,

IMHO, the more meaningful cases of the RFC are missing :

round(float, precision: >= 0): int|float // only cast to float for int overflow
ceil(float): int|float // only cast to float for int overflow
floor(float): int|float // only cast to float for int overflow

Calling ceil or floor on integer is meaningless, because it will return the same value.
The RFC should be “Prefer int as return value when possible”.

I do believe it’s important to avoid unnecessary casts as much as possible and leave it up to the user making cast explicit than implicit else the behavior gets quite unpredictable.

Implicitly casting to float only happens on int underflow/overflow. Implicitly casting to int will never happen.

As you say “Calling ceil or floor on integer is meaningless, because it will return the same value.” this is already noted in the RFC and the functions will be a no-op in this case.

Best regards,
Marc

8

Hey Marc,

On 18.3.2024 08:53:01, Marc Bennewitz wrote:

Hi Bob,

On 17.03.24 14:59, Bob Weinand wrote:

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

Hey Marc,

I've voted no; it should be just changed without any force_float parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly cast via (float).

The effective BC break of that would be quite small if some things which return float today now would return int. I cannot imagine many cases where this would actually be unwanted. And as said, explicit (float) casts are always possible.

I also dislike force_float, as it cannot just be added to a function in any code which shall be backwards compatible to 8.3 and older. It would just emit Uncaught Error: Unknown named parameter $force_float.

Changing the return type from float to int is a non trivial quite hard to find behavior change.

Imaging code like this:

$x = 800;
$y = 800;
round($x/$y) === 1.0;

This will return false instead of true especially because we teach users to use strict comparison.
Such behavior change should be done in a major version.

I see, here we disagree:
- Strict comparison should be avoided when working with numbers. Strict comparisons are generally for strings and booleans.
- There's no reason to artificially wait years here.

With the additional parameter it's possible to opt-in into the new behavior already in 8.4 while in PHP 9.0 the default behavior will change but previously opted in code does not need to get touched again.

Just changing the behavior means waiting for PHP 9.0 without a way to opt-in in 8.4 already. If you are not interested in opting in in 8.4 already you can just ignore the additional argument as this will be the default in 9.0.

I'm not interested in having an additional parameter I have to carry forward for quite some years.

To mimic the previous behavior in a fully BC way it's as simple as explicitly casting the value to float.

I would rather have preferred to see a static analysis solution how often round()ed results are compared strictly, assess the actual BC impact and possibly encourage tools like Rector to recognize such patterns.

Bob

Regards,
Marc

Bob

9

Hi Bob, and sorry for the late reply ...

On 19.03.24 01:05, Bob Weinand wrote:

Hey Marc,

On 18.3.2024 08:53:01, Marc Bennewitz wrote:

Hi Bob,

On 17.03.24 14:59, Bob Weinand wrote:

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

Best regards,

Marc Bennewitz

Hey Marc,

I've voted no; it should be just changed without any force_float parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly cast via (float).

The effective BC break of that would be quite small if some things which return float today now would return int. I cannot imagine many cases where this would actually be unwanted. And as said, explicit (float) casts are always possible.

I also dislike force_float, as it cannot just be added to a function in any code which shall be backwards compatible to 8.3 and older. It would just emit Uncaught Error: Unknown named parameter $force_float.

Changing the return type from float to int is a non trivial quite hard to find behavior change.

Imaging code like this:

$x = 800;
$y = 800;
round($x/$y) === 1.0;

This will return false instead of true especially because we teach users to use strict comparison.
Such behavior change should be done in a major version.

I see, here we disagree:
- Strict comparison should be avoided when working with numbers. Strict comparisons are generally for strings and booleans.
- There's no reason to artificially wait years here.

Agree, strict comparison should be avoided when working with numbers but this detail normally does not get mentioned if an "equal vs. same" discussion comes up and there are even coding styles out there forcing users to use strict comparison everywhere like

- coding-standard/SlevomatCodingStandard/Sniffs/Operators/DisallowEqualOperatorsSniff.php at master · slevomat/coding-standard · GitHub
- laminas-coding-standard/src/LaminasCodingStandard/ruleset.xml at 2.6.x · laminas/laminas-coding-standard · GitHub

With the additional parameter it's possible to opt-in into the new behavior already in 8.4 while in PHP 9.0 the default behavior will change but previously opted in code does not need to get touched again.

Just changing the behavior means waiting for PHP 9.0 without a way to opt-in in 8.4 already. If you are not interested in opting in in 8.4 already you can just ignore the additional argument as this will be the default in 9.0.

I'm not interested in having an additional parameter I have to carry forward for quite some years.

To mimic the previous behavior in a fully BC way it's as simple as explicitly casting the value to float.

I would rather have preferred to see a static analysis solution how often round()ed results are compared strictly, assess the actual BC impact and possibly encourage tools like Rector to recognize such patterns.

As of the above reason and because the rounding functions are very highly used functions I think it's obvious that such behavior change will break a lot of code out there.

I'm a bit confused because normally possible BC breaks have to be avoided as much as possible and if a feature is ranked higher it still needs to smooth migration but here it seems to me now it's fine to break a lot of users code without warning and without a way to opt-in before (which was requested previously).

Bob

Regards,
Marc

Bob

10

Hi internals,

On 17.03.24 13:23, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
PHP: rfc:integer-rounding

Do to Easter weekend the vote will run for two weeks and two days until Tue the 2nd of April 2024.

The RFC has been declined with 18 votes against and 0 in favor.

Kind regards,
Marc Bennewitz