| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:null_coercion_consistency [2022/05/09 23:20] – Fix 'do not' typo craigfrancis | rfc:null_coercion_consistency [2022/05/11 10:59] – Add note about adding types to userland libraries without BC breaks (thanks Aleksander) craigfrancis |
|---|
| $search = $request->getGet('q'); // CodeIgniter | $search = $request->getGet('q'); // CodeIgniter |
| |
| $value = array_pop($empty_array); | |
| $value = mysqli_fetch_row($result); | $value = mysqli_fetch_row($result); |
| $value = json_decode($json); // Invalid JSON, or nesting limit. | $value = json_decode($json); // Invalid JSON, or nesting limit. |
| | $value = array_pop($empty_array); |
| </code> | </code> |
| |
| |
| <code php> | <code php> |
| | $rounded_value = round($value); |
| | |
| $search_trimmed = trim($search); | $search_trimmed = trim($search); |
| |
| "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 (which can a be useful check for static analysis, or in the context of //strict_types=1//). | "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). In theory "it should be possible for existing userland libraries to add scalar type declarations without breaking compatibility", but this was not the case, because of NULL. Talking to developers, the only reason mentioned (noted above) is where NULL can be viewed as a missing/invalid value, and passing NULL to a function like //htmlspecialchars()// could indicate a problem (which can a be useful check for static analysis, or in the context of //strict_types=1//). |
| |
| The function //mt_rand()// can be called with no arguments, or with min and max integer arguments. A developer may call //mt_rand(NULL, NULL)// and expect it to work the same as no arguments (returning a random number between 0 and //mt_getrandmax()//), but the NULL's would be coerced to 0, so it would always return 0. That said, I cannot find any public examples of this happening ([[https://grep.app/search?q=mt_rand%28NULL&filter%5Blang%5D%5B0%5D=PHP|1]], [[https://grep.app/search?q=mt_rand%5Cs%2A%5C%28%5Cs%2ANULL®exp=true&filter[lang][0]=PHP|2]], [[https://www.google.com/search?q=%22mt_rand+NULL+NULL%22|3]]). | The function //mt_rand()// can be called with no arguments, or with min and max integer arguments. A developer may call //mt_rand(NULL, NULL)// and expect it to work the same as no arguments (returning a random number between 0 and //mt_getrandmax()//), but the NULL's would be coerced to 0, so it would always return 0. That said, I cannot find any public examples of this happening ([[https://grep.app/search?q=mt_rand%28NULL&filter%5Blang%5D%5B0%5D=PHP|1]], [[https://grep.app/search?q=mt_rand%5Cs%2A%5C%28%5Cs%2ANULL®exp=true&filter[lang][0]=PHP|2]], [[https://www.google.com/search?q=%22mt_rand+NULL+NULL%22|3]]). |