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

This is not a default value (i.e. you can use = null in middle of required parameters), but defacto a nullable parameter type. Default values should and will always be changeable between functions in an inheritance tree. And while it's a tiny BC break, one can very easily fix the function from function (array $foo = []) { ... } to function (array $foo = null) { if (!$foo) { $foo = []; } ... } Which satisfies all of todays and future code. Thanks, Bob > Am 28.04.2016 um 20:34 schrieb Dmitry Stogov <dmitry@zend.com>: > > PHP method compatibility rules didn't take into account default values of arguments. > Adding new rule is not just a bug fix, and breaks existing code. > > ________________________________________ > From: Bob Weinand <bobwei9@hotmail.com> > Sent: Thursday, April 28, 2016 9:12:54 PM > To: Dmitry Stogov > Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison > Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values > > Yeah, > It's a BC break; hence I've accepted it being reverted from 7.0. > I've only put the fix back in 7.1 thus. > > Or is it your opinion that we shall hold a formal RFC vote for a glaring bug? That sounds > pretty much like a waste of everyones time to me. RFC votes IMO are for cases where we don't > have clear consensus. Or is really anyone disputing this fix? > > Bob Weinand (iPhone) > >> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov <dmitry@zend.com>: >> >> This is a "fix", that introduces BC break. >> Even if I see a reason in this check, it's still a break. >> If you remember, we voted for almost for every BC break during PHP-7.0 development. >> >> >> ________________________________________ >> From: Bob Weinand <bobwei9@hotmail.com> >> Sent: Thursday, April 28, 2016 8:36:22 PM >> To: Dmitry Stogov >> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison >> Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return >> values >> >>> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmitry@zend.com>: >>> >>> 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 >> >> Hey Dmitry, >> >> thanks for reverting… but >> >> I've seen you had merged just straight up? >> I assume this was unintentional (as it should definitely remain fixed in 7.1). >> Thus I've reverted your changes in master (only) and added an appropriate NEWS entry >> there. >> >> Thanks, >> Bob >