Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92874
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.110.110 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>
CC: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>, "Tom
 Worster" <fsb@thefsb.org>
Thread-Topic: Request to withdraw RFC's for nullable types for only return
 values
Thread-Index: AQHRoWRe782dRDYm1kuNWD0UZVTnlZ+fm7+pgAAF6QCAAAEy1Q==
Date: Thu, 28 Apr 2016 17:28:59 +0000
Message-ID: <BY2PR0201MB178486D1A9DE2D597C522289BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4NpBi80uJ-_-==4Wd5h87k=fq3h7N9ygph1kCHg9Czc_Kw@mail.gmail.com>
	<BY2PR0201MB17848D27325287FFD9785771BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>,<CAL=_i_kYSCeRzr15fRJRAjN3LBiqJQbUNz=sNYGCs5B3WgLMqQ@mail.gmail.com>
In-Reply-To: <CAL=_i_kYSCeRzr15fRJRAjN3LBiqJQbUNz=sNYGCs5B3WgLMqQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB178486D1A9DE2D597C522289BF650BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 17:28:59.5286
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: Request to withdraw RFC's for nullable types for only return
 values
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB178486D1A9DE2D597C522289BF650BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

hi Joe,


No problem, great it's fixed before 7.0.6 release.

I think this change might be introduced only together with nullable or unio=
n types.

Otherwise it makes a problem, described by Levi, that doesn't allow running=
 the same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.


Thanks. Dmitry.


________________________________
From: Joe Watkins <pthreads@pthreads.org>
Sent: Thursday, April 28, 2016 8:20:12 PM
To: Dmitry Stogov
Cc: Levi Morrison; internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return v=
alues

Evening Dmitry,

This was discussed at length with bob, and I think nikita also, it seemed l=
ike a bug fix rather than a feature.

Happy for it to be moved into 7.1 ... sorry for dropping the ball there ...

Cheers
Joe

On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov <dmitry@zend.com<mailto:dmit=
ry@zend.com>> wrote:
Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires=
 RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets addition=
al question.

Thanks. Dmitry.

________________________________________
From: morrison.levi@gmail.com<mailto:morrison.levi@gmail.com> <morrison.lev=
i@gmail.com<mailto:morrison.levi@gmail.com>> on behalf of Levi Morrison <le=
vim@php.net<mailto:levim@php.net>>
Sent: Thursday, April 28, 2016 6:40:59 PM
To: internals
Cc: Dmitry Stogov; Tom Worster
Subject: Request to withdraw RFC's for nullable types for only return value=
s

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


--_000_BY2PR0201MB178486D1A9DE2D597C522289BF650BY2PR0201MB1784_--