rfc:coercive_sth

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:coercive_sth [2015/03/11 13:06]
zeev More mods
rfc:coercive_sth [2020/08/01 23:52] (current)
carusogabriel Status is "Declined"
Line 3: Line 3:
   * Date: 2015-02-27   * Date: 2015-02-27
   * Authors: Zeev Suraski <​zeev@php.net>,​ Francois Laupretre <​francois@php.net>,​ Dmitry Stogov <​dmitry@php.net>​   * Authors: Zeev Suraski <​zeev@php.net>,​ Francois Laupretre <​francois@php.net>,​ Dmitry Stogov <​dmitry@php.net>​
-  * Status: ​Under discussion+  * Status: ​Declined
   * First Published at: http://​wiki.php.net/​rfc/​coercive_sth   * First Published at: http://​wiki.php.net/​rfc/​coercive_sth
- 
-===== Preamble ===== 
- 
-This version is published as '​near-final',​ and with the exception of potential minor modifications,​ is what will be proposed for a vote. 
  
 ===== Background & Summary ===== ===== Background & Summary =====
Line 133: Line 129:
   "​8.2"​ -> int           # "​8.2"​ cannot be converted to an integer without data loss   "​8.2"​ -> int           # "​8.2"​ cannot be converted to an integer without data loss
   4.3 -> bool            # No more conversion from float to bool   4.3 -> bool            # No more conversion from float to bool
-  "​foo"​ -> bool          # No more conversion from string to bool 
   "7 dogs" -> int        # Non-blank trailing characters no longer supported   "7 dogs" -> int        # Non-blank trailing characters no longer supported
   "3.14 pizzas"​ -> float # Non-blank trailing characters no longer supported ​   "3.14 pizzas"​ -> float # Non-blank trailing characters no longer supported ​
Line 153: Line 148:
 Numerous community members have invested substantial effort into creating another comprehensive RFC, that proposes to introduce STH into PHP [[https://​wiki.php.net/​rfc/​scalar_type_hints_v5|Scalar Type Hints RFC v0.5 ("Dual Mode RFC"​)]]. ​ However, we believe the proposal in this RFC is better, for several different reasons: Numerous community members have invested substantial effort into creating another comprehensive RFC, that proposes to introduce STH into PHP [[https://​wiki.php.net/​rfc/​scalar_type_hints_v5|Scalar Type Hints RFC v0.5 ("Dual Mode RFC"​)]]. ​ However, we believe the proposal in this RFC is better, for several different reasons:
  
-  - **Single Mode.** ​ Thanks to the fact this RFC proposes a single mode and enables it across the board for any code that's run, you get the benefit of stricter-yet-sensible rules overnight. ​ Thanks to the good signal-to-noise ratio, moving to PHP 7 is likely to help people find bugs, without having to proactively enable stricter modes.+  - **Single Mode.** ​ Thanks to the fact this RFC proposes a single mode and enables it across the board for any code that's run, you get the benefit of stricter-yet-sensible rules overnight. ​ Thanks to the good signal-to-noise ratio, moving to PHP 7 is likely to help people find real world bugs, without having to proactively enable stricter modes and without having to introduce a lot of changes to their code.
   - **Smaller cognitive burden.** ​ Even though the Dual Mode RFC presents a novel idea about how to allow developers to choose which mode they'd like to use, and use different modes in different parts of the app, it still introduces the burden of two different modes. ​ Two different rule-sets that need to be learned increase the language'​s complexity. ​ Further, the two sets can cause the same functions to behave differently depending on where they'​re being called, and potentially a new class of bugs stemming from developers not realizing which mode they'​re in in a particular file.  This RFC is unaffected by these issues, as it presents a single, composite rule set.   - **Smaller cognitive burden.** ​ Even though the Dual Mode RFC presents a novel idea about how to allow developers to choose which mode they'd like to use, and use different modes in different parts of the app, it still introduces the burden of two different modes. ​ Two different rule-sets that need to be learned increase the language'​s complexity. ​ Further, the two sets can cause the same functions to behave differently depending on where they'​re being called, and potentially a new class of bugs stemming from developers not realizing which mode they'​re in in a particular file.  This RFC is unaffected by these issues, as it presents a single, composite rule set.
   - **Too strict may lead to too lax.** In the Dual Mode RFC, when in Strict mode, in many cases, functions would reject values that, semantically,​ are acceptable. ​ For example, a "​32"​ (string) value coming back from an integer column in a database table, would not be accepted as valid input for a function expecting an integer. ​ Since semantically the developer is interested in this argument-passing succeeding, they would have the choice of either removing the integer STH altogether, or, more likely, explicitly casting the value into an integer. ​ This would have the opposite of the desired outcome of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, and would happily convert "100 dogs", "​Apples"​ and even arrays and booleans into an integer. ​ Further, since already today, internal functions employ coercion rules that are more restrictive than PHP's explicit casting, pushing people towards explicit casting will actually make things **worse** in case developers opt for explicit casting as they pass values in an internal function call.    - **Too strict may lead to too lax.** In the Dual Mode RFC, when in Strict mode, in many cases, functions would reject values that, semantically,​ are acceptable. ​ For example, a "​32"​ (string) value coming back from an integer column in a database table, would not be accepted as valid input for a function expecting an integer. ​ Since semantically the developer is interested in this argument-passing succeeding, they would have the choice of either removing the integer STH altogether, or, more likely, explicitly casting the value into an integer. ​ This would have the opposite of the desired outcome of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, and would happily convert "100 dogs", "​Apples"​ and even arrays and booleans into an integer. ​ Further, since already today, internal functions employ coercion rules that are more restrictive than PHP's explicit casting, pushing people towards explicit casting will actually make things **worse** in case developers opt for explicit casting as they pass values in an internal function call. 
   - **Smooth integration with Data Sources**. ​ PHP uses strings extensively across the language, and in most cases, data sources always feed data into PHP as strings. ​ PHP applications rely extensively on internal type juggling to convert that string-based data according to the needed context. ​ Strict zval.type based STH effectively eliminates this behavior, moving the burden of worrying about type conversion to the user.  The solution proposed in this RFC allows code that relies on type coercion to Just Work when the values are sensible, but fail (and appropriately warn the developer) otherwise.   - **Smooth integration with Data Sources**. ​ PHP uses strings extensively across the language, and in most cases, data sources always feed data into PHP as strings. ​ PHP applications rely extensively on internal type juggling to convert that string-based data according to the needed context. ​ Strict zval.type based STH effectively eliminates this behavior, moving the burden of worrying about type conversion to the user.  The solution proposed in this RFC allows code that relies on type coercion to Just Work when the values are sensible, but fail (and appropriately warn the developer) otherwise.
 +  - **Forward compatibility for internal function calls**. ​ Codebases which will be tested & improved to work on PHP 7, can run without a problem on PHP 5 and benefit from the improved code quality.
  
  
Line 181: Line 176:
   * **Static Analysis** - Analyzing code without running it, attempting to derive conclusions about security, performance,​ etc.   * **Static Analysis** - Analyzing code without running it, attempting to derive conclusions about security, performance,​ etc.
  
-===== Proposed Voting Choices ​===== +===== Vote ===== 
-The voting choices ​would be yes/no.+The voting choices ​are yes (in favor for accepting this RFC for PHP 7) or no (against it).
 The RFC proposes a very substantial change to PHP's coercion rules, which may evolve to affect implicit typing in the future. The RFC proposes a very substantial change to PHP's coercion rules, which may evolve to affect implicit typing in the future.
-It absolutely requires a 2/3 majority, with the hope of reaching as close as possible to consensus.+It absolutely requires a 2/3 majority, with the hope of reaching as close as possible to consensus. ​ The vote starts on March 11th, and will end two weeks later, on March 25th. 
 + 
 +<doodle title="​coercive_sth"​ auth="​zeev"​ voteType="​single"​ closed="​true">​ 
 +   * Yes 
 +   * No 
 +</​doodle>​
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
 https://​github.com/​php/​php-src/​pull/​1125/​files https://​github.com/​php/​php-src/​pull/​1125/​files
rfc/coercive_sth.1426079213.txt.gz · Last modified: 2017/09/22 13:28 (external edit)