Differences

This shows you the differences between two versions of the page.

--- rfc:null_coercion_consistency [2022/05/05 11:21] – Add note about arithmetics craigfrancis
+++ rfc:null_coercion_consistency [2022/05/09 10:53] – Update Backward Incompatible Changes (thanks Mel) craigfrancis
@@ Line 45: / Line 45: @@
   - [[https://www.php.net/manual/en/language.types.boolean.php|To Boolean]]: "When converting to bool, the following values are considered false [...] the special type NULL"
-For example:
+==== Current State ====
 <code php>
@@ Line 116: / Line 116: @@
 ==== Examples ====
-A simple search page:
-<code php>
-$name = $request->get('name');
-if (trim($name) === '') { // Contains non-whitespace characters; so not "", " ", NULL, etc
-  $where_sql[] = 'name LIKE ?';
-  $where_val[] = $name;
-}
-echo '
-  <form action="./" method="get">
-    <label>
-      Search
-      <input type="search" name="name" value="' . htmlspecialchars($name) . '">
-    </label>
-    <input type="submit" value="Go">
-  </form>';
-if ($name !== NULL) {
-  $register_url = '/admin/accounts/add/?name=' . urlencode($name);
-  echo '
-    <p><a href="' . htmlspecialchars($register_url) . '">Add Account</a></p>';
-}
-</code>
-Note how line 1 cannot simply be updated to force //$name// to be non-nullable, as it would break the "Add Account" link. But does passing NULL to //htmlspecialchars()// and //trim()// justify a Fatal Type Error?
-I'd argue this very strict level of type checking is best done by Static Analysis, which can check if a variable can be nullable, and it can decide if this is a problem, in the same way that a string (e.g. '15') being provided to integer parameter could be seen as a problem.
 Common sources of NULL:
@@ Line 199: / Line 169: @@
 mail('nobody@example.com', 'subject', 'message', NULL, '-fwebmaster@example.com');
 </code>
+HTML Templating engines like [[https://github.com/laravel/framework/blob/ab1506091b9f166b312b3990d07b2e21d971f2e6/src/Illuminate/Support/helpers.php#L119|Laravel Blade]] suppress this deprecation with null-coalescing ([[https://github.com/laravel/framework/pull/36262/files#diff-15b0a3e2eb2d683222d19dfacc04c616a3db4e3d3b3517e96e196ccbf838f59eR118|patch]]); or [[https://github.com/twigphp/Twig/blob/b4d6723715da57667cca851051eba3786714290d/src/Extension/EscaperExtension.php#L195|Symphony Twig]] which preserves NULL, but it's often passed to //echo// (which accepts it, despite the [[https://www.php.net/echo|echo documentation]] saying it accepts non-nullable strings).
+I'd argue a very strict level of type checking (that prevents all forms of coercion) is best done by Static Analysis, which can check if a variable can be nullable, and it can decide if this is a problem, in the same way that a string (e.g. '15') being provided to integer parameter could be seen as a problem.
 There are approximately [[https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-change.md|335 parameters affected by this deprecation]].
@@ Line 341: / Line 315: @@
 ===== Backward Incompatible Changes =====
-None
+While the intention of this RFC is to avoid a BC break; for user defined functions to be updated to also coerce NULL (instead of throwing a Type Error), it's possible some code may rely on that behaviour, for example:
+<code php>
+function my_function(string $my_string) {
+  var_dump($my_string);
+}
+try {
+  my_function('A');   // string(1) "A"
+  my_function(1);     // string(1) "1"
+  my_function(1.2);   // string(3) "1.2"
+  my_function(true);  // string(1) "1"
+  my_function(false); // string(0) ""
+  my_function(NULL);  // Throw Type Error
+} catch (TypeError $e) {
+  // Do something important?
+}
+</code>
 ===== Proposed PHP Version(s) =====

Differences

Page Tools