Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Bob Weinand]

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)
> 
>> 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
>> 
>>> 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.l...@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
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[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)

> 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
>
>> 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.l...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Bob Weinand]

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
> 
>> 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.l...@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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[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

> 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.l...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

all these are good points not to commit BC breaks in hurry.


From: Joe Watkins 
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 
> wrote:

> 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.l...@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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Joe Watkins]

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  wrote:

>
> > 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.l...@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

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Bob Weinand]

> 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.l...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Request to withdraw RFC's for nullable types for only return values

[Levi Morrison]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php