rfc:stricter_implicit_boolean_coercions

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:stricter_implicit_boolean_coercions [2022/05/31 15:46] – iquitorfc:stricter_implicit_boolean_coercions [2022/06/20 16:00] (current) – Change status to declined and close voting iquito
Line 3: Line 3:
   * Date: 2022-05-16   * Date: 2022-05-16
   * Author: Andreas Leathley, <a.leathley@gmx.net>   * Author: Andreas Leathley, <a.leathley@gmx.net>
-  * Status: Under Discussion+  * Status: Declined
   * First Published at: http://wiki.php.net/rfc/stricter_implicit_boolean_coercions   * First Published at: http://wiki.php.net/rfc/stricter_implicit_boolean_coercions
  
Line 160: Line 160:
 ^ From bool    | always possible (coerced to "" or "1") | always possible (coerced to 0 or 1)                      | always possible (coerced to 0 or 1)         |                                  | ^ From bool    | always possible (coerced to "" or "1") | always possible (coerced to 0 or 1)                      | always possible (coerced to 0 or 1)         |                                  |
  
-This RFC would further reduce the gap between strict mode and coercive mode, as even in coercive mode no information would be lost when coercing a scalar value and only values that are reasonable are accepted (otherwise a deprecation notice is emitted). All allowed coercions can be reversed to end up with the original value or almost the same ("0" can become "" and vice versa) - that is something this RFC makes possible, as without this RFC reversing a coercion to boolean will often not lead back to the original value. These examples illustrate reversibility and the loss of information:+This RFC would further reduce the gap between strict mode and coercive mode, as even in coercive mode no information would be lost when coercing a scalar value and only values that are reasonable are accepted (otherwise a deprecation notice is emitted). All allowed coercions can be reversed to end up with the original value or almost the same ("0" can become "") - that is something this RFC makes possible, as without this RFC reversing a coercion to boolean will often not lead back to the original value. These examples illustrate reversibility and the loss of information:
  
 <PHP> <PHP>
Line 232: Line 232:
 ===== Future Scope ===== ===== Future Scope =====
  
-While this RFC only targets boolean coercions when not using strict_types, the overall goal is to have a solid and easy-to-understand foundation of type coercions between scalar values, and coercions to booleans are the biggest missing piece when looking at that.+While this RFC only targets boolean coercions when not using strict_types, this is just the last missing piece for the overall goal of having a solid and easy-to-understand foundation of type coercions between scalar values.
  
-One benefit of these well-developed coercions could be to make them available in an explicit way to PHP developers. Having functions like ''is_coerceable_to_bool'' and ''coerce_to_bool'' (and with similar functions for int, float and string) that behave exactly as giving a value to a boolean argument could be useful when receiving input from a form or database. Compared to the current explicit type coercions (''(bool)'', ''boolval'', ''(int)'' or ''(float)'') this would allow only a certain subset of values instead of coercing any value, giving developers an effective way to make sure they are dealing with values that make sense - or fail early if an unexpected value is encountered. And because it is based on the type coercion behavior of PHP the learning curve would be low.+One benefit of these well-developed coercions could be to make them available in an explicit way to PHP developers. Having functions like ''is_coerceable_to_bool'' and ''coerce_to_bool'' (and with similar functions for int, float and string) that behave exactly as giving a value to a boolean argument could be useful when receiving input from a form or database. Compared to the current explicit type coercions (''(bool)'', ''boolval'', ''(int)'' or ''(float)'') this would allow only a certain subset of values instead of coercing any value, giving developers an effective way to make sure they are dealing with values that make sense - or fail early if an unexpected value is encountered. And because it is based on the type coercion behavior of PHP the learning curve would be low and the knowledge would be universally useful within the language.
  
 An example of how these functions could look like can be found on Github in [[https://github.com/squirrelphp/scalar-types|squirrelphp/scalar-types]] (written in PHP). This is just a preliminary example that would need to be discussed further with a follow-up RFC. An example of how these functions could look like can be found on Github in [[https://github.com/squirrelphp/scalar-types|squirrelphp/scalar-types]] (written in PHP). This is just a preliminary example that would need to be discussed further with a follow-up RFC.
Line 248: Line 248:
   * Implicit boolean expressions (as used in if, ternary, logic operators) are not affected.   * Implicit boolean expressions (as used in if, ternary, logic operators) are not affected.
   * FILTER_VALIDATE_BOOLEAN in the filter extension is not affected.   * FILTER_VALIDATE_BOOLEAN in the filter extension is not affected.
 +  
 +===== Vote =====
 +
 +Voting started on 2022-06-06 and will end on 2022-06-20.
 +
 +<doodle title="Accept Stricter implicit boolean coercions RFC as proposed?" auth="iquito" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
rfc/stricter_implicit_boolean_coercions.1654011987.txt.gz · Last modified: 2022/05/31 15:46 by iquito

Page Tools