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

> Am 28.04.2016 um 19:28 schrieb Dmitry Stogov <dmitry@zend.com>: > > hi Joe, > > > No problem, great it's fixed before 7.0.6 release. > > I think this change might be introduced only together with nullable or union types. > > Otherwise it makes a problem, described by Levi, that doesn't allow running the same code > in PHP-7.0 and 7.1, and even doesn't allow an ease fix. > > > Thanks. Dmitry. > > > ________________________________ > From: Joe Watkins <pthreads@pthreads.org> > Sent: Thursday, April 28, 2016 8:20:12 PM > To: Dmitry Stogov > Cc: Levi Morrison; internals; Tom Worster > Subject: 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<mailto: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<mailto:morrison.levi@gmail.com> > <morrison.levi@gmail.com<mailto:morrison.levi@gmail.com>> > on behalf of Levi Morrison > <levim@php.net<mailto: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 > Uhm … reading this, it sounds like it was intentional … if yes, then sorry. But it still allows an easy fix, just pass the value explicitly. I think we should leave the fix in 7.1 thus. The bug itself - violating LSP - must be fixed. The only reason why it's fine in 7.0 is BC. But it definitely MUST be fixed in 7.1. Bob