| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:null_coercion_consistency [2022/04/11 16:32] – Update note about user-defined functions specifying parameter types (thanks George Peter Banyard) craigfrancis | rfc:null_coercion_consistency [2022/04/15 07:32] – Feedback from George P. Banyard craigfrancis |
|---|
| |
| There was a [[https://externals.io/message/112327|short discussion]] about the original RFC, but with the exception of Craig Duncan, there was no consideration for the problems this creates with existing code (or the inconsistency of NULL coercion compared to string/int/float/bool coercion). | There was a [[https://externals.io/message/112327|short discussion]] about the original RFC, but with the exception of Craig Duncan, there was no consideration for the problems this creates with existing code (or the inconsistency of NULL coercion compared to string/int/float/bool coercion). |
| | |
| | The general direction of [[https://github.com/Girgias/unify-typing-modes-rfc|Unify PHP's typing modes]] by Girgias is correct, because automatic coercions like //substr($string, "offset")// and //htmlspecialchars(array())// are clearly problematic; but the following is common, and has been fine: |
| | |
| | <code php> |
| | $search = filter_input(INPUT_GET, 'q'); // Or similar examples below. |
| | |
| | echo 'Results for ' . htmlspecialchars($search); |
| | </code> |
| |
| ===== Problem ===== | ===== Problem ===== |
| NULL can usually be coerced, but... | NULL can usually be coerced, but... |
| |
| - PHP 7.0 introduced the ability for user-defined functions to specify parameter types via the [[https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks|Scalar Type Declarations RFC]], where the focus was on //strict_types=1//. But the implementation also caused Type Errors when not using //strict_types=1//, which seems more of an over-sight (breaking null coercion, and introducing a type check, for an environment that does not expect this). | - PHP 7.0 introduced the ability for user-defined functions to specify parameter types via the [[https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks|Scalar Type Declarations RFC]], where the focus was on //strict_types=1//. But the implementation also caused Type Errors when not using //strict_types=1//, which seems more of an over-sight, with coercion working for string/int/float/bool but not null (despite the documentation), and introducing a type check (for an environment that does not expect this). |
| - PHP 8.1 continued this inconsistency with internal functions. | - PHP 8.1 continued this inconsistency with internal functions. |
| |
| |
| "it's a bit late" - We only have a deprecation at the moment (which can and is being ignored), it will be "too late" when PHP 9.0 uses Fatal Errors. | "it's a bit late" - We only have a deprecation at the moment (which can and is being ignored), it will be "too late" when PHP 9.0 uses Fatal Errors. |
| | |
| | "Userland scalar types [...] did not include coercion from NULL for //very// good reasons." - The only reason mentioned in [[https://wiki.php.net/rfc/scalar_type_hints_v5|Scalar Type Declarations]] is "to be consistent with our existing type declarations" (no further details given). Talking to developers, the only reason mentioned is noted above, where NULL can be viewed as a missing/invalid value, and passing NULL to a function like //htmlspecialchars()// could indicate a problem (while that might be useful in the context of //strict_types=1//, it hasn't been the case for everyone else). |
| |
| ===== Future Scope ===== | ===== Future Scope ===== |