Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Request to withdraw RFC's for nullable types for only return values »

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

php.internals

Levi Morrison

10 years ago
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

Dmitry Stogov

10 years ago
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

Bob Weinand

10 years ago
> 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

Joe Watkins

10 years ago
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 On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

Dmitry Stogov

10 years ago
all these are good points not to commit BC breaks in hurry. ________________________________ From: Joe Watkins <pthreads@pthreads.org> Sent: Thursday, April 28, 2016 8:41:34 PM To: Bob Weinand Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values 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 On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand <bobwei9@hotmail.com<mailto:bobwei9@hotmail.com>> wrote:
> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>>: > > Hi, > > The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511 > > Author: Joe Watkins <krakjoe@php.net<mailto: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<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 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

Dmitry Stogov

10 years ago
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

Bob Weinand

10 years ago
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)

Dmitry Stogov

10 years ago
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)

Bob Weinand

10 years ago
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

Dmitry Stogov

10 years ago
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

Joe Watkins

10 years ago
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:

Dmitry Stogov

10 years ago
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

Bob Weinand

10 years ago
> 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

Levi Morrison

10 years ago
On Thu, Apr 28, 2016 at 11:07 AM, 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.
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?

Dmitry Stogov

10 years ago
your Nullable RFC doesn't propose working implementation. ________________________________________ From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> 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 On Thu, Apr 28, 2016 at 11:07 AM, 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.
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?

Levi Morrison

10 years ago
On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> your Nullable RFC doesn't propose working implementation. > > ________________________________________ > From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> > 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 > > On Thu, Apr 28, 2016 at 11:07 AM, 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. > > 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.

Dmitry Stogov

10 years ago
I'm not happy with the fact, that you propose two competing RFCs, support only one and trying to withdraw other competitors. ________________________________________ From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> Sent: Thursday, April 28, 2016 8:47:41 PM To: Dmitry Stogov Cc: internals; Tom Worster Subject: Re: Request to withdraw RFC's for nullable types for only return values On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> your Nullable RFC doesn't propose working implementation. > > ________________________________________ > From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> > 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 > > On Thu, Apr 28, 2016 at 11:07 AM, 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. > > 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.

Joe Watkins

10 years ago
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 On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison <levim@php.net> wrote:

Levi Morrison

10 years ago
On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> 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 > > On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison <levim@php.net> wrote: >> >> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmitry@zend.com> wrote: >> > your Nullable RFC doesn't propose working implementation. >> > >> > ________________________________________ >> > From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of >> > Levi Morrison <levim@php.net> >> > 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 >> > >> > On Thu, Apr 28, 2016 at 11:07 AM, 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. >> > >> > 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. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >
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.

Dmitry Stogov

10 years ago
Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types". ________________________________________ From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> Sent: Thursday, April 28, 2016 9:47:18 PM To: Joe Watkins Cc: Dmitry Stogov; internals; Tom Worster Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins <pthreads@pthreads.org> wrote:
> 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 > > On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison <levim@php.net> wrote: >> >> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmitry@zend.com> wrote: >> > your Nullable RFC doesn't propose working implementation. >> > >> > ________________________________________ >> > From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of >> > Levi Morrison <levim@php.net> >> > 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 >> > >> > On Thu, Apr 28, 2016 at 11:07 AM, 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. >> > >> > 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. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >
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.

Levi Morrison

10 years ago
On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> 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.

Dmitry Stogov

10 years ago
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 <morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net> 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 On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> 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.