I have discovered through a [bug report][1] a case where having
explicitly nullable parameters would be of value.
<?php
interface Foo {
public function bar(array $baz = null);
}
class Hello implements Foo {
public function bar(array $baz = array()) {}
}
?>
You can theoretically change the default value in a sub-type, but in
this case moving away from the default value of null breaks because
the subtype no longer permits null. It is important to realize that we
previously *allowed* this behavior since PHP 5.1 but was fixed in
7.0.6.
If instead we had nullable types separately from default values of
null this could change to:
<?php
class Hello implements Foo {
public function bar(array | null $baz = []) {}
}
?>
(or a short-form `?array $baz = []` if short-form passes)
This preserves the ability to be null but changes the default value.
Of course, there may be other code changes necessary to future-proof
their code but there current code would now work without having to
rewrite any method bodies (just signatures).
In light of this I kindly request that RFCs that add nullable types
for only return values be withdrawn. So that [Union Types][2] and
[Nullable Types][3] can go forward unhindered.
[1]: https://bugs.php.net/bug.php?id=72119
[2]: https://wiki.php.net/rfc/union_types
[2]: https://wiki.php.net/rfc/nullable_types
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
