# Request to withdraw RFC's for nullable types for only return values - Thread: https://externals.io/message/92868 - Original archive: https://news-web.php.net/php.internals/92868 - Started by Levi Morrison on 2016-04-28T15:40:59+00:00 - Messages: 24 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #92868 — Levi Morrison — 2016-04-28T15:40:59+00:00 URL: https://externals.io/message/92868#92868 I have discovered through a [bug report][1] a case where having explicitly nullable parameters would be of value. 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: (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 --- ## #92871 — Dmitry Stogov — 2016-04-28T16:28:03+00:00 URL: https://externals.io/message/92868#92871 · In reply to: #92868 Hi, The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511 Author: Joe Watkins 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. --- ## #92872 — Dmitry Stogov — 2016-04-28T17:07:10+00:00 URL: https://externals.io/message/92868#92872 · In reply to: #92868 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. --- ## #92873 — Joe Watkins — 2016-04-28T17:20:12+00:00 URL: https://externals.io/message/92868#92873 · In reply to: #92872 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 > 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 on behalf of Levi > Morrison > 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. > > > 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: > > > 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 --- ## #92874 — Dmitry Stogov — 2016-04-28T17:28:59+00:00 URL: https://externals.io/message/92868#92874 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. --- ## #92876 — Bob Weinand — 2016-04-28T17:36:22+00:00 URL: https://externals.io/message/92868#92876 · In reply to: #92871 > Am 28.04.2016 um 18:28 schrieb Dmitry Stogov : > > Hi, > > The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511 > > Author: Joe Watkins > 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 on behalf of Levi Morrison > 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. > > > 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: > > > 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 --- ## #92877 — Levi Morrison — 2016-04-28T17:39:03+00:00 URL: https://externals.io/message/92868#92877 · In reply to: #92872 > 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. In that case: are you fine with my RFCs going to vote first (and soon)? We presently have four somewhat competing RFCs and need to work out voting order. Tom: are you willing to withdraw or wait for my RFCs to vote first? --- ## #92879 — Joe Watkins — 2016-04-28T17:41:34+00:00 URL: https://externals.io/message/92868#92879 · In reply to: #92876 The problem is as Levi explained though Bob, don't we actually require nullables/unions for that case ? Maybe we can move forward now, confident that by the time 7.1 is released we will have one of those things ? The problems with that are, the RFC's for unions/intersections don't match the implementation, and none of us have a good idea how to implement the RFCs. In addition, nobody can agree which nullable types RFC should go to vote, or how the whole nullable type question should be resolved. Cheers Joe > > > […] > ee9a78a033696ff9546fb1dbfecd28f20477b511 > > […] > code. > > […] > Levi Morrison > > […] > values > > […] > > 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 --- ## #92881 — Dmitry Stogov — 2016-04-28T17:43:10+00:00 URL: https://externals.io/message/92868#92881 your Nullable RFC doesn't propose working implementation. --- ## #92882 — Bob Weinand — 2016-04-28T17:47:35+00:00 URL: https://externals.io/message/92868#92882 · In reply to: #92874 > Am 28.04.2016 um 19:28 schrieb Dmitry Stogov : > > 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 > 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 > > > 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 > on behalf of Levi Morrison > > 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. > > > 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: > > > 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 --- ## #92883 — Levi Morrison — 2016-04-28T17:47:41+00:00 URL: https://externals.io/message/92868#92883 · In reply to: #92881 > your Nullable RFC doesn't propose working implementation. > > ________________________________________ > From: morrison.levi@gmail.com on behalf of Levi Morrison > Sent: Thursday, April 28, 2016 8:39:03 PM > To: Dmitry Stogov > Cc: internals; Tom Worster > Subject: Re: Request to withdraw RFC's for nullable types for only return values > > > > […] > > In that case: are you fine with my RFCs going to vote first (and > soon)? We presently have four somewhat competing RFCs and need to work > out voting order. > > Tom: are you willing to withdraw or wait for my RFCs to vote first? It doesn't have an implementation, sure. But you already worked out return types, the basics are already there in parameter types and there's an implementation in HHVM. Do you really think this would be a blocker? There is no reason to believe that a short-hand nullable types implementation cannot be reasonably done. --- ## #92884 — Dmitry Stogov — 2016-04-28T17:48:50+00:00 URL: https://externals.io/message/92868#92884 all these are good points not to commit BC breaks in hurry. --- ## #92885 — Dmitry Stogov — 2016-04-28T17:55:05+00:00 URL: https://externals.io/message/92868#92885 I'm not happy with the fact, that you propose two competing RFCs, support only one and trying to withdraw other competitors. --- ## #92886 — Joe Watkins — 2016-04-28T17:55:29+00:00 URL: https://externals.io/message/92868#92886 · In reply to: #92883 Levi, Why do you need to block Dmitry's return type nullable RFC ? We need to move forward, that has an implementation, ready for a long time, doesn't seem to block nullable parameter types rfc, either separately or as part of unions. So, I'm not understanding why you need to hold up Dmitry any more. Please, explain. Cheers Joe > > > […] > Levi Morrison > > […] > return values > > […] > requires RFC and definitely not allowed in minor versions. > > […] > https://wiki.php.net/rfc/nullable_return_types > > […] > additional question. > > […] > > It doesn't have an implementation, sure. But you already worked out > return types, the basics are already there in parameter types and > there's an implementation in HHVM. Do you really think this would be a > blocker? There is no reason to believe that a short-hand nullable > types implementation cannot be reasonably done. --- ## #92887 — Dmitry Stogov — 2016-04-28T17:59:02+00:00 URL: https://externals.io/message/92868#92887 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. --- ## #92889 — Bob Weinand — 2016-04-28T18:12:54+00:00 URL: https://externals.io/message/92868#92889 · In reply to: #92887 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 : > > 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 > 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 > > > […] > > 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 --- ## #92890 — Dmitry Stogov — 2016-04-28T18:34:00+00:00 URL: https://externals.io/message/92868#92890 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. --- ## #92892 — Levi Morrison — 2016-04-28T18:47:18+00:00 URL: https://externals.io/message/92868#92892 · In reply to: #92886 > Levi, > > Why do you need to block Dmitry's return type nullable RFC ? > > We need to move forward, that has an implementation, ready for a long > time, doesn't seem to block nullable parameter types rfc, either separately > or as part of unions. > > So, I'm not understanding why you need to hold up Dmitry any more. > > Please, explain. > > Cheers > Joe > > > > […] > Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort of political campaign. Let me try to straighten this: As evidenced by this bug report that needs a fix there is a need for nullable parameter types that is not tied to a default of null. Dmitry's RFC does not handle this. Nor does Tom's. There is an RFC that can solve both return types and parameter types. I'm asking them to withdraw because they don't meet those needs and there is an RFC that does. It just so happens to be mine. It also happens to be the first drafted RFC. This is not an unreasonable request. In fact, it's the much nicer option that just opening vote on mine first without talking about it on list at all. And lastly, it's just a request. They don't have to withdraw. --- ## #92893 — Dmitry Stogov — 2016-04-28T18:54:16+00:00 URL: https://externals.io/message/92868#92893 Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types". --- ## #92895 — Levi Morrison — 2016-04-28T19:02:20+00:00 URL: https://externals.io/message/92868#92895 · In reply to: #92893 > Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types". I don't understand; I wrote the RFC. What do you mean, "keep trying to own" it? I wrote both Nullable Types and Union Types. Some view those RFC's as competing, but they can also be orthogonal. I see the value in having both. --- ## #92896 — Dmitry Stogov — 2016-04-28T19:16:44+00:00 URL: https://externals.io/message/92868#92896 Levi, I provided an implementation for your RFC on February 2015, and I would be glad if your RFC was accepted that time. Bit since that time you block it in respect to "Union Types" See conversation at PR https://github.com/php/php-src/pull/1045 I would be also glad if your "Nullable Types" RFC was accepted now, but I don't trust in your intention to support it. --- ## #92898 — Bob Weinand — 2016-04-28T19:28:13+00:00 URL: https://externals.io/message/92868#92898 · In reply to: #92890 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 : > > 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 > 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) > > > […] --- ## #92902 — Tom Worster — 2016-04-28T20:40:53+00:00 URL: https://externals.io/message/92868#92902 · In reply to: #92896 Levi, From one reasonable point of view, Union and Nullable are in conflict with each other. If one prefers Union then one might argue in favor of Union over related but different proposals. When it comes to the vote, it's difficult to support both except with the argument that "I can settle for Nullable if Union doesn't pass vote", which, when you think about it, is not really supporting both. If Union goes to vote before anything else, voters will to take into account what they expect to subsequently go to vote. So your stance relative to that matters. Hence it's not really clear what you want while you continue to own both. This is how I understand Dmitry's concerns (correct me if I'm wrong, Dmitry). It would be easier to understand if you would *either* abandon Union (for 7.1) and throw your support behind Nullable *or* disown Nullable, let Dmitry champion it, and the two RFCs to vote as alternatives. I understand that you see Union as a kind of superset of Nullable (correct me if I'm wrong) but when it comes to the voting, there's no fair way to organize that. Someone's going to be unhappy. Tom >Levi, I provided an implementation for your RFC on February 2015, and I >would be glad if your RFC was accepted that time. >Bit since that time you block it in respect to "Union Types" > >See conversation at PR https://github.com/php/php-src/pull/1045 > >I would be also glad if your "Nullable Types" RFC was accepted now, but I >don't trust in your intention to support it. > >________________________________________ >From: morrison.levi@gmail.com on behalf of Levi >Morrison >Sent: Thursday, April 28, 2016 10:02:20 PM >To: Dmitry Stogov >Cc: Joe Watkins; internals; Tom Worster >Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types >for only return values > > > > […] > >I don't understand; I wrote the RFC. What do you mean, "keep trying to >own" it? I wrote both Nullable Types and Union Types. Some view those >RFC's as competing, but they can also be orthogonal. I see the value >in having both. --- ## #92905 — Dmitry Stogov — 2016-04-28T21:19:23+00:00 URL: https://externals.io/message/92868#92905 More or less right. It's easy to archive the "right" goal, if you own the both football teams.