Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92890
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.118 as permitted sender)
To: Bob Weinand <bobwei9@hotmail.com>
CC: Anatol Belski <ab@php.net>, Joe Watkins <pthreads@pthreads.org>, internals
	<internals@lists.php.net>, Levi Morrison <levim@php.net>
Thread-Topic: [PHP-DEV] Request to withdraw RFC's for nullable types for only
 return values
Thread-Index: AQHRoWRe782dRDYm1kuNWD0UZVTnlZ+fkd6TgAAUTgCAAAVaWoAABNwAgAAE7Fk=
Date: Thu, 28 Apr 2016 18:34:00 +0000
Message-ID: <BY2PR0201MB17840CE280484085D43D6383BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4NpBi80uJ-_-==4Wd5h87k=fq3h7N9ygph1kCHg9Czc_Kw@mail.gmail.com>
 <BY2PR0201MB178406C8680E019383635391BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <BLU436-SMTP9813204E424AA3BC7DE123E2650@phx.gbl>
 <BY2PR0201MB1784F3A14E496526825AAA75BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>,<DUB406-EAS4335FD09C071629BBDED202E2650@phx.gbl>
In-Reply-To: <DUB406-EAS4335FD09C071629BBDED202E2650@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 18:34:00.4915
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1784
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only
 return values
From: dmitry@zend.com (Dmitry Stogov)

PHP method compatibility rules didn't take into account default values of a=
rguments.
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 onl=
y 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 bu=
g? 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 de=
velopment.
>
>
> ________________________________________
> 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 o=
nly 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 ee9a78a033696ff9546fb1d=
bfecd28f20477b511
>>
>> 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 Lev=
i 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 va=
lues
>>
>> 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 =3D null);
>> }
>>
>> class Hello implements Foo {
>>   public function bar(array $baz =3D 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 =3D [])  {}
>> }
>>
>> ?>
>>
>> (or a short-form `?array $baz =3D []` 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=3D72119
>> [2]: https://wiki.php.net/rfc/union_types
>> [2]: https://wiki.php.net/rfc/nullable_types
>
> Hey Dmitry,
>
> thanks for reverting=85 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