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

Evening Dmitry, This was discussed at length with bob, and I think nikita also, it seemed like a bug fix rather than a feature. Happy for it to be moved into 7.1 ... sorry for dropping the ball there ... Cheers Joe On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov <dmitry@zend.com> wrote: > Thanks for catching the BC break. > Fortunately, we didn't release 7.0.6 with this problem. > > I see some sense in introducing that check, but changing behaviour > requires RFC and definitely not allowed in minor versions. > > I'm not going to withdraw > https://wiki.php.net/rfc/nullable_return_types > It doesn't prohibit usage of nullable for arguments, and even sets > additional question. > > Thanks. Dmitry. > > ________________________________________ > From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi > Morrison <levim@php.net> > Sent: Thursday, April 28, 2016 6:40:59 PM > 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 >