RoundFunctionReturnTypeExtension supports types with ConstantScalar

[ShioPy0101]

Returns a constant type when the $num argument and the relevant options of round(), ceil(), or floor() can be resolved to constant values.

Constant numeric strings are also evaluated in non-strict mode.

round() also supports the RoundingMode enum cases corresponding to the legacy PHP_ROUND_HALF_* constants.

The default return type is used when constant evaluation is not possible, for example when:

• the precision is not a single constant integer;
• the rounding mode is not a single supported constant;
• the input contains unsupported constant values.

[staabm]

which problem does this change solve? whats your real world use-case?

[zonuexe]

@staabm

I'm sure there are several use cases for this, but one I quickly spotted in my private code is the following pattern, which uses $last_page for some logic other than just printing it.

Ideally it would be even more useful if a float range type was implemented, but I feel like this is worthwhile enough on its own.

const MAX = 1000;
const PER_PAGE = 30;
$last_page = (int)floor(MAX / PER_PAGE);

https://phpstan.org/r/b583dc30-3b4e-4b1f-af60-713159f43309

[VincentLanglet]

Hi @ShioPy0101, are you still interested by this PR ? Could you rebase and target 2.3.x branch ?

[github-advanced-security]

octoscan found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[github-advanced-security]

zizmor found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[ShioPy0101]

Hi @VincentLanglet, I’ve rebased the PR onto 2.3.x and updated the target branch. Could you take another look when you have a chance?

Thank you for bringing this PR back to my attention.

[VincentLanglet]

You could return null directly no ?

[ShioPy0101]

Yes, you're right. I'll simplify this to return null directly.

[VincentLanglet]

Why this check ?

I saw in test you have the assertion

assertType('float', round($IntOrNumStr));

but can't we also understand '2.5' ?

[ShioPy0101]

Thank you for pointing this out. I agree that constant numeric strings can also be handled in non-strict mode. I’ll update the implementation and tests while preserving the strict-types behavior.

[VincentLanglet]

There is now new RoundingMode
https://www.php.net/manual/en/enum.roundingmode.php

[ShioPy0101]

Thanks for pointing it out — I’ll update the implementation for the current PHP versions.

[VincentLanglet]

Seems good otherwise

[VincentLanglet]

Why this mapping ?

This loose some case.

assertType('float', round(9.5, 0, \RoundingMode::TowardsZero));
	assertType('float', round(9.5, 0, \RoundingMode::AwayFromZero));
	assertType('float', round(9.5, 0, \RoundingMode::NegativeInfinity));
	assertType('float', round(9.5, 0, \RoundingMode::PositiveInfinity));

You could keep the original value when the Enum exists no ?

[ShioPy0101]

I intentionally limited the mapping to the four RoundingMode cases that have direct equivalents in the legacy PHP_ROUND_HALF_* constants. The intent was to avoid making constant evaluation depend on the runtime availability of the RoundingMode enum.

For the remaining cases, I currently fall back to the existing return-type logic because they do not have a direct legacy constant mapping.

That said, I agree that this is an implementation limitation rather than a limitation of RoundingMode itself. Preserving the enum case internally would allow all cases to be evaluated more precisely, so I think that would be a better direction.

[ShioPy0101]

I am still considering the best approach here. The README states that PHPStan's source code is developed on PHP 8.2, while the distributed package and PHAR are transformed to run on PHP 7.2 and higher. Given that, I would prefer to avoid making constant evaluation depend on the runtime availability of RoundingMode.

[VincentLanglet]

Any suggestion @staabm ?