rfc:safe_cast

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:safe_cast [2014/11/19 20:34]
ajf Opened vote
rfc:safe_cast [2014/11/29 21:20]
ajf end(ed)
Line 1: Line 1:
 ====== PHP RFC: Safe Casting Functions ====== ====== PHP RFC: Safe Casting Functions ======
-  * Version: 0.1.7+  * Version: 0.1.8
   * Date: 2014-10-20, Last Updated 2014-11-14   * Date: 2014-10-20, Last Updated 2014-11-14
   * Author: Andrea Faulds, ajf@ajf.me   * Author: Andrea Faulds, ajf@ajf.me
-  * Status: In Voting+  * Status: Declined
   * First Published at: http://wiki.php.net/rfc/safe_cast   * First Published at: http://wiki.php.net/rfc/safe_cast
  
Line 9: Line 9:
  
 Currently, PHP only provides one means of type conversion: explicit casts. These casts never fail or emit errors, making them dangerous to use, as when passed garbage input, they will simply return garbage instead of indicating that something went wrong. This makes it difficult to write robust applications which handle user data. They also prevent any suggestion of strict type hinting for scalar types, because if that were to be added, users would simply use dangerous explicit casts to get around errors and the result would be code that is buggier than it would have been without type hinting at all. Currently, PHP only provides one means of type conversion: explicit casts. These casts never fail or emit errors, making them dangerous to use, as when passed garbage input, they will simply return garbage instead of indicating that something went wrong. This makes it difficult to write robust applications which handle user data. They also prevent any suggestion of strict type hinting for scalar types, because if that were to be added, users would simply use dangerous explicit casts to get around errors and the result would be code that is buggier than it would have been without type hinting at all.
 +
 +For int and float conversion specifically, ''ext/filter'' provides ''FILTER_VALIDATE_INT'' and ''FILTER_VALIDATE_FLOAT''. ''filter_var($foo, FILTER_VALIDATE_INT)'' and ''filter_var($foo, FILTER_VALIDATE_FLOAT)''. However, these are rather unwieldy, encouraging people to use the shorter explicit casts, and suffer from a performance and safety standpoint by their converting values to strings before validating (allowing, for example, booleans, or objects with ''__toString''). Furthermore, their use requires explicit error handling by checking for a FALSE return value. If the programmer forgets to check it, they are no safer than explicit casts.
  
 ===== Proposal ===== ===== Proposal =====
Line 14: Line 16:
 Two families of "safe casting" functions are added to ''ext/standard'', ''try_''* and ''to_''*, for ''int'', ''float'' and ''string''. These functions validate their input to ensure data is not lost with the cast (thus the cast can be considered safe), instead of casting blindly. If the input fails to validate, the ''to_''* functions throw a ''CastException'', while the ''try_''* functions return NULL. If validation succeeds, the converted result is returned. Two families of "safe casting" functions are added to ''ext/standard'', ''try_''* and ''to_''*, for ''int'', ''float'' and ''string''. These functions validate their input to ensure data is not lost with the cast (thus the cast can be considered safe), instead of casting blindly. If the input fails to validate, the ''to_''* functions throw a ''CastException'', while the ''try_''* functions return NULL. If validation succeeds, the converted result is returned.
  
-''to_int()'' and ''try_int()'' accept only ints, non-NaN integral floats within the range of an integer (''PHP_INT_MIN'' to ''PHP_INT_MAX''), and strings containing decimal integer sequences within the range of an integer. Leading and trailing whitespace is not permitted, nor are leading zeros or a positive sign.+''to_int()'' and ''try_int()'' accept only ints, non-NaN integral floats within the range of an integer (''PHP_INT_MIN'' to ''PHP_INT_MAX''), and strings containing decimal integer sequences within the range of an integer. Leading and trailing whitespace is not permitted, nor are leading zeros.
  
-''to_float()'' and ''try_float()'' accept only ints, floats, and strings representing floats. Leading and trailing whitespace is not permitted, nor are leading zeros or a positive sign.+''to_float()'' and ''try_float()'' accept only ints, floats, and strings representing floats. Leading and trailing whitespace is not permitted, nor are leading zeros.
  
 ''to_string()'' and ''try_string()'' accept only strings, objects which cast to strings, ints and floats. ''to_string()'' and ''try_string()'' accept only strings, objects which cast to strings, ints and floats.
Line 92: Line 94:
 ===== Open Issues ===== ===== Open Issues =====
  
-While I'd prefer to return NULL on error, it would also be possible to return FALSE. As this seems to be relatively controversial, it will be put to a vote.+None.
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
Line 108: Line 110:
 ==== Vote ==== ==== Vote ====
  
-<doodle title="Should the Safe Casting Functions RFC be accepted, and the patch merged into master?" auth="ajf" voteType="single" closed="false">+Voting opened 2014-11-19 and ended 2014-11-29. 
 + 
 +<doodle title="Should the Safe Casting Functions RFC be accepted, and the patch merged into master?" auth="ajf" voteType="single" closed="true">
    * Yes    * Yes
    * No    * No
Line 137: Line 141:
 ===== Changelog ===== ===== Changelog =====
  
 +  * v0.1.8 - ext/filter note in Introduction
   * v0.1.7 - Allow positive signs   * v0.1.7 - Allow positive signs
   * v0.1.6 - Dropped zero round trip data loss principle, added octal and whitespace rationale   * v0.1.6 - Dropped zero round trip data loss principle, added octal and whitespace rationale
rfc/safe_cast.txt · Last modified: 2017/09/22 13:28 (external edit)