Re: Request to withdraw RFC's for nullable types for only return values

Hi, The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511 Author: Joe Watkins <krakjoe@php.net> Date: Mon Mar 28 11:54:25 2016 +0100 Late, there were few more commits that changed and moved the problematic code. Anatol, I think we should revert this before 7.0.6 release. Thanks. Dmitry. ________________________________________ From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> Sent: Thursday, April 28, 2016 18:40 To: internals Cc: Dmitry Stogov; Tom Worster Subject: Request to withdraw RFC's for nullable types for only return values 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