Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92876
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.140 as permitted sender)
Message-ID: <BLU436-SMTP9813204E424AA3BC7DE123E2650@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <BY2PR0201MB178406C8680E019383635391BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 28 Apr 2016 19:36:22 +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>
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)


> 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
>=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

Hey Dmitry,

thanks for reverting=E2=80=A6 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=