rfc:null_coercion_consistency

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
Next revisionBoth sides next revision
rfc:null_coercion_consistency [2022/04/11 16:35] – craigfrancisrfc:null_coercion_consistency [2022/04/15 07:34] – craigfrancis
Line 23: Line 23:
  
 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 =====
Line 123: Line 131:
 </code> </code>
  
-Examples where NULL has previously been fine for scripts not using //strict_types=1//:+Examples, often working with user input, where NULL has previously been fine:
  
 <code php> <code php>
Line 147: Line 155:
 </code> </code>
  
-And developers have used //NULL// to skip certain parameters, e.g.+And developers have used NULL to skip certain parameters, e.g.
  
 <code php> <code php>
 setcookie('q', $search, NULL, NULL, NULL, true, true); // x4 setcookie('q', $search, NULL, NULL, NULL, true, true); // x4
 +
 +substr($string, NULL, 3);
  
 mail('nobody@example.com', 'subject', 'message', NULL, '-fwebmaster@example.com'); mail('nobody@example.com', 'subject', 'message', NULL, '-fwebmaster@example.com');
Line 163: Line 173:
 The only realistic way for developers to find when NULL is passed to these internal functions is to use the deprecation notices (not ideal). The only realistic way for developers to find when NULL is passed to these internal functions is to use the deprecation notices (not ideal).
  
-It is possible to use very strict Static Analysis, to follow every variable from source to sink (to check if a variable could be //NULL//), but most developers are not in a position to do this (i.e. not using static analysis, or not at a high enough level, or they are using a baseline to ignore).+It is possible to use very strict Static Analysis, to follow every variable from source to sink (to check if a variable could be NULL), but most developers are not in a position to do this (i.e. not using static analysis, or not at a high enough level, or they are using a baseline to ignore).
  
 In the last JetBrains developer survey, where 67% regularly used Laravel, **only 33% used Static Analysis** ([[https://www.jetbrains.com/lp/devecosystem-2021/php/#PHP_do-you-use-static-analysis|source]]); where it's fair to say many still would not identify these possible NULL values. In the last JetBrains developer survey, where 67% regularly used Laravel, **only 33% used Static Analysis** ([[https://www.jetbrains.com/lp/devecosystem-2021/php/#PHP_do-you-use-static-analysis|source]]); where it's fair to say many still would not identify these possible NULL values.
Line 323: Line 333:
  
 "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 =====
Line 345: Line 357:
 ===== Rejected Features ===== ===== Rejected Features =====
  
-Did consider updating some parameters to accept NULL ([[https://wiki.php.net/rfc/allow_null|details]]).+  - Updating some parameters to accept NULL ([[https://wiki.php.net/rfc/allow_null|details]]). This was rejected because some developers view NULL as a missing/invalid value that should never be passed to functions like //htmlspecialchars()// ([[https://quiz.craigfrancis.co.uk/|quiz results]]).
  
 ===== Notes ===== ===== Notes =====
rfc/null_coercion_consistency.txt · Last modified: 2023/10/18 11:57 by craigfrancis

Page Tools