Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.174 as permitted sender)
Message-ID: <BLU436-SMTP21633A3E3CB80F0E607E716E2650@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <BY2PR0201MB17840CE280484085D43D6383BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 28 Apr 2016 21:28:13 +0200
CC: Anatol Belski <ab@php.net>,
 Joe Watkins <pthreads@pthreads.org>,
 internals <internals@lists.php.net>,
 Levi Morrison <levim@php.net>
Content-Transfer-Encoding: quoted-printable
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> <BY2PR0201MB17840CE280484085D43D6383BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values
From: bobwei9@hotmail.com (Bob Weinand)

This is not a default value (i.e. you can use =3D 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 =3D []) { ... }
to
function (array $foo =3D null) { if (!$foo) { $foo =3D []; } ... }

Which satisfies all of todays and future code.

Thanks,
Bob

> Am 28.04.2016 um 20:34 schrieb Dmitry Stogov <dmitry@zend.com>:
>=20
> 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.
>=20
> ________________________________________
> 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
>=20
> 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.
>=20
> 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?
>=20
> Bob Weinand (iPhone)
>=20
>> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov <dmitry@zend.com>:
>>=20
>> 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.
>>=20
>>=20
>> ________________________________________
>> 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
>>=20
>>> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmitry@zend.com>:
>>>=20
>>> Hi,
>>>=20
>>> The BC break in PHP-7.0 was introduced by commit =
ee9a78a033696ff9546fb1dbfecd28f20477b511
>>>=20
>>> Author: Joe Watkins <krakjoe@php.net>
>>> Date:   Mon Mar 28 11:54:25 2016 +0100
>>>=20
>>> Late, there were few more commits that changed and moved the =
problematic code.
>>>=20
>>> Anatol, I think we should revert this before 7.0.6 release.
>>>=20
>>> Thanks. Dmitry.
>>>=20
>>> ________________________________________
>>> 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
>>>=20
>>> I have discovered through a [bug report][1] a case where having
>>> explicitly nullable parameters would be of value.
>>>=20
>>> <?php
>>>=20
>>> interface Foo {
>>>  public function bar(array $baz =3D null);
>>> }
>>>=20
>>> class Hello implements Foo {
>>>  public function bar(array $baz =3D array())  {}
>>> }
>>>=20
>>> ?>
>>>=20
>>> 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.
>>>=20
>>> If instead we had nullable types separately from default values of
>>> null this could change to:
>>>=20
>>> <?php
>>>=20
>>> class Hello implements Foo {
>>>  public function bar(array | null $baz =3D [])  {}
>>> }
>>>=20
>>> ?>
>>>=20
>>> (or a short-form `?array $baz =3D []` if short-form passes)
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>>=20
>>> [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
>>=20
>> Hey Dmitry,
>>=20
>> thanks for reverting=85 but
>>=20
>> 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.
>>=20
>> Thanks,
>> Bob
>=20