Implicit conversion from int to float should report a loses precision error too

[kkmuffme]

Description

The following code:

<?php
$x = PHP_INT_MAX + 1;

Resulted in this output:

But I expected this output instead:

Deprecated: Implicit conversion from int 9223372036854775807 to float loses precision

This error already exists the other way round https://3v4l.org/4C3ru#v8.4.8
Also see #17081

PHP Version

PHP 8.4.8

Operating System

No response

[Girgias]

This is long-standing behaviour and requires an RFC.

If you want this to land in time for 8.5 you need to publish the RFC within the next week as feature freeze is on the 12th of August and there needs 4 weeks minimum to go from start of discussion to end of voting for an RFC.

As the author of the RFC that deprecated the float to int I can see why this behaviour existed in the first place, as a 32bit integer was always representable as a double. This is a 64 bit problem "only".

I think taking inspiration of JS and introducing an equivalent to Number.MAX_SAFE_INTEGER makes sense.

If you want to write an RFC feel free to reach out, but unless an RFC is written this will likely be closed as a won't fix.

[nielsdos]

FWIW, I think that adding a MAX_SAFE_INT constant, or whatever you want to call it in PHP, is sensible on its own.

[mvorisek]

In JS, the constant is present as integers are stored in double. In php, this is not the case.

I however highly support a notice warning when an integer overflows in integer operation.

[nielsdos]

In JS, the constant is present as integers are stored in double. In php, this is not the case.

Yes, but when coercion happens to a floating point number, or when some computations result in doubles, it will be a double anyway.