PHP RFC: Deprecate implicit non-integer-compatible float to int conversions


PHP is a dynamically typed language and as such implicit type coercion naturally arises, most of these are harmless and rather convenient. However, float to int conversions can lead to data loss such as when the float is outside the platform integer range, or it has a fractional part. This extends to the conversion of float strings when converted to int.


A float is said to be integer-compatible if posses the following characteristics:

  • Is a number (i.e. not NaN or Infinity)
  • Is in range of a PHP integer (platform dependent)
  • Has no fractional part


Emit an E_DEPRECATED deprecation diagnostic for implicit conversion from float and float strings to int if the floating point number is not integer-compatible.

If the conversion happens from a float the diagnostic message is:

Implicit conversion to int from non-compatible float %f

If the conversion happens from a float-string the diagnostic message is:

Implicit conversion to int from non-compatible float-string %s

Where %f and %s correspond to the value of the float/float-string value which is not integer-compatible.

Raise these deprecation diagnostics to TypeError in the next major version (PHP 9.0).


Following the changes in behaviour and definition of numeric strings in PHP 8 1) 2) it should be a reasonable expectation to safely be able to use PHP's type juggling from string to integer as such data can come from a variety of places (HTTP request, database query, text file, etc. ). However, because floats, and by extension float strings, get silently converted to int there is no way to know if the data provided is erroneous and/or provokes data loss.

The lack of possibility of knowing if data loss arises necessitates the use of the strict_type mode, which is an issue in itself when using a function which returns a float but given the input arguments an int compatible return is to be expected, this mostly affects mathematical functions, the most notable example being the round() function when passing a non-positive precision.

The use of a float or float string as a string offset already emits a warning as it needs to perform a conversion, this proposal would generalize this aspect to other areas of PHP.

Finally, attempting to pass a float or float string which exceeds the range representable by an int as an argument to a parameter with an int type declaration already causes a TypeError to be thrown, regardless of typing mode.

Implementation notes

A new C function is_long_compatible() is introduced which performs a round trip (i.e. (double)(zend_long)) check to establish if a float is integer-compatible.

A new zend_dval_to_lval_safe() C function is introduced which performs a check to is_long_compatible() that if it fails will emit the deprecation diagnostic.

The zend_get_long_func() is modified to accept an additional argument named is_lax, which purpose is to toggle between using zend_dval_to_lval() or zend_dval_to_lval_safe(), as this function is used by the (int) cast.

Backward Incompatible Changes

The following operations will now emit an E_DEPRECATED if a non-integer-compatible floats or float string is used:

  • Bitwise OR operator |
  • Bitwise AND operator &
  • Bitwise XOR operator ^
  • Shift right and left operators
  • Modulo operator
  • The combined assignment operators of the above operators
  • Assignment to a typed property of type int in coercive typing mode
  • Argument for a parameter of type int for both internal and userland functions in coercive typing mode
  • Returning such a value for userland functions declared with a return type of int in coercive typing mode

The following operations will now emit an E_DEPRECATED if a non-integer-compatible float is used:

  • Bitwise NOT operator ~
  • As an array key

Proposed PHP Version

Next minor version: PHP 8.1.

RFC Impact

To Existing Extensions

Test output might need to be adjusted as the zval_get_long() (and TBD convert_to_long()) will call the new zend_dval_to_lval_safe() function instead of zend_dval_to_lval()

Extensions which call directly zend_get_long_func() will need to be adjusted to either use zval_get_long() or pass explicitly the new lax flag.

To OPcache

Rules about accepting floats instead of int would need to be reviewed as emitting diagnostics pose an issue from my understanding

Unaffected PHP Functionality

  • Manually casting to integer will not raise a notice.
  • Integer to float implicit conversions are not affected.
  • Strict Type behaviour is unaffected.
  • The behaviour of passing float strings as an array key.
  • The behaviour of passing a float or float string as a string offset.
  • A bitwise NOT ~ operation on a float string is still performed with string semantics.

Future Scope

  • Possibility to normalize float strings for array keys.
  • Possibility to allow compatible float and float strings for string offsets.
  • Normalize behaviour when casting to int from out-of-range float.

Proposed Voting Choices

As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.

Accept Deprecate implicit non-integer-compatible float to int conversions RFC proposal
Real name Yes No
alcaeus (alcaeus)  
asgrim (asgrim)  
ashnazg (ashnazg)  
crell (crell)  
daverandom (daverandom)  
derick (derick)  
galvao (galvao)  
girgias (girgias)  
ilutov (ilutov)  
kalle (kalle)  
kguest (kguest)  
kocsismate (kocsismate)  
lcobucci (lcobucci)  
marandall (marandall)  
mariano (mariano)  
nikic (nikic)  
ocramius (ocramius)  
patrickallaert (patrickallaert)  
pierrick (pierrick)  
pollita (pollita)  
reywob (reywob)  
santiagolizardo (santiagolizardo)  
sergey (sergey)  
svpernova09 (svpernova09)  
tandre (tandre)  
theodorejb (theodorejb)  
thorstenr (thorstenr)  
trowski (trowski)  
twosee (twosee)  
Final result: 29 0
This poll has been closed.

Patches and Tests


After the project is implemented, this section should contain

  1. the version(s) it was merged into
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature
  4. a link to the language specification section (if any)


Initial mailing list discussion: <https://externals.io/message/113077>
Revised mailing list discussion: <https://externals.io/message/113371>

rfc/implicit-float-int-deprecate.txt · Last modified: 2021/04/14 11:39 by girgias