rfc:integer_semantics

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:integer_semantics [2014/09/14 22:46] – v0.2.2 - Added examples ajfrfc:integer_semantics [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== PHP RFC: Integer Semantics ====== ====== PHP RFC: Integer Semantics ======
-  * Version: 0.2.2+  * Version: 0.2.3
   * Date: 2014-08-19   * Date: 2014-08-19
   * Author: Andrea Faulds <ajf@ajf.me>   * Author: Andrea Faulds <ajf@ajf.me>
-  * Status: In Voting+  * Status: Implemented
   * First Published at: http://wiki.php.net/rfc/integer_semantics   * First Published at: http://wiki.php.net/rfc/integer_semantics
  
Line 44: Line 44:
 "Negative shifts" do not do what users would reasonably expect them to do: shift in the opposite direction. Rather, a negative shift is usually a shift by the 2's complement unsigned integer representation (in the case of ''-2'', this would be ''18446744073709551614'' when integers are 64-bit). This is also reliant on undefined behaviour in C, and will give different results depending on the processor and integer size. For this reason, we now disallow such shifts. "Negative shifts" do not do what users would reasonably expect them to do: shift in the opposite direction. Rather, a negative shift is usually a shift by the 2's complement unsigned integer representation (in the case of ''-2'', this would be ''18446744073709551614'' when integers are 64-bit). This is also reliant on undefined behaviour in C, and will give different results depending on the processor and integer size. For this reason, we now disallow such shifts.
  
-On Intel CPUs, a bitwise shift by a number of bits that is greater than the bit width of an integer (e.g. ''>> 65'' on a 64-bit machine) will "wrap around" (e.g. ''>> 65'' is effectively ''>> 1''). To ensure cross-platform consistency, we ensure that such shifts shifts will always result in zero (for left shifts), or zero or negative one (for right shifts, depending on the sign of the number being shifted). It is worth noting that shifts of a number of bits greater than the bit width of an integer is also undefined behaviour in C.+On Intel CPUs, a bitwise shift by a number of bits that is greater than the bit width of an integer (e.g. ''>> 65'' on a 64-bit machine) will "wrap around" (e.g. ''>> 65'' is effectively ''>> 1''). To ensure cross-platform consistency, we ensure that such shifts will always result in zero (for left shifts), or zero or negative one (for right shifts, depending on the sign of the number being shifted). It is worth noting that shifts of a number of bits greater than the bit width of an integer is also undefined behaviour in C.
  
 Making NaN and Infinity always become zero when casted to integer means more cross-platform consistency, and is also less surprising than what is currently produces, where NaN produces the minimum integer on my machine (''-9223372036854775808''). Making NaN and Infinity always become zero when casted to integer means more cross-platform consistency, and is also less surprising than what is currently produces, where NaN produces the minimum integer on my machine (''-9223372036854775808'').
Line 57: Line 57:
  
 Integer to float conversion is untouched. Despite some people's misconceptions, the bitwise shift operators do not operate on strings like the other bitwise operators do, so I have not affected how they deal with strings as they didn't in the first place (they cast to integer). This does not touch the behaviour of array key casting (except for Infinity and NaN), although this is something I would like to do Integer to float conversion is untouched. Despite some people's misconceptions, the bitwise shift operators do not operate on strings like the other bitwise operators do, so I have not affected how they deal with strings as they didn't in the first place (they cast to integer). This does not touch the behaviour of array key casting (except for Infinity and NaN), although this is something I would like to do
- 
-===== Open Questions/Possible Future Scope ===== 
- 
-Currently PHP throws an ''E_WARNING'' and gives ''FALSE'' for a division by zero, and under this RFC, so would shifts by negative counts. While not strictly an //integer// semantics issue, should we make division by zero result in Infinity/-Infinity per IEEE 754, and perhaps make it throw no error, or an E_NOTICE? If we did that, should we make this return NaN instead? 
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
Line 73: Line 69:
  
 ===== Implementation ===== ===== Implementation =====
-After the project is implemented, this section should contain  + 
-  - the version(s) it was merged to +Merged into master. It will be in PHP 7. 
-  - a link to the git commit(s) + 
-  - a link to the PHP manual entry for the feature+It is not yet in the manual.
  
 ===== Vote ===== ===== Vote =====
Line 82: Line 78:
 As this is a language change, a 2/3 majority is required. As this is a language change, a 2/3 majority is required.
  
-Voting started 2014-09-14 and ends 2014-09-21.+Voting started 2014-09-14 and ended on 2014-09-21.
  
-<doodle title="Accept the integer semantics RFC and merge patch into master?" auth="ajf" voteType="single" closed="false">+<doodle title="Accept the integer semantics RFC and merge patch into master?" auth="ajf" voteType="single" closed="true">
    * Yes    * Yes
    * No    * No
Line 98: Line 94:
 ===== Changelog ===== ===== Changelog =====
  
 +  * v0.2.3 - Removed "Open Questions/Possible Future Scope" to avoid confusion
   * v0.2.2 - Added examples   * v0.2.2 - Added examples
   * v0.2.1 - Open Questions/Possible Future Scope added   * v0.2.1 - Open Questions/Possible Future Scope added
rfc/integer_semantics.1410734761.txt.gz · Last modified: 2017/09/22 13:28 (external edit)