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

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