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 <dmi...@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 <bobw...@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 <dmi...@zend.com>:
>>
>> Hi,
>>
>> The BC break in PHP-7.0 was introduced by commit
>> ee9a78a033696ff9546fb1dbfecd28f20477b511
>>
>> Author: Joe Watkins <krak...@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.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi
>> Morrison <le...@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
