Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92884
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.110.137 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>, Bob Weinand <bobwei9@hotmail.com>
CC: Anatol Belski <ab@php.net>, 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+fkd6TgAAUTgCAAAF0AIAAANSJ
Date: Thu, 28 Apr 2016 17:48:50 +0000
Message-ID: <BY2PR0201MB1784938EAF870F2F45CF0CC8BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4NpBi80uJ-_-==4Wd5h87k=fq3h7N9ygph1kCHg9Czc_Kw@mail.gmail.com>
	<BY2PR0201MB178406C8680E019383635391BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<BLU436-SMTP9813204E424AA3BC7DE123E2650@phx.gbl>,<CAL=_i_n+gqC5e4qy2r7OaLtR_uLce8T=4xOeJxjZyZoAsOvacg@mail.gmail.com>
In-Reply-To: <CAL=_i_n+gqC5e4qy2r7OaLtR_uLce8T=4xOeJxjZyZoAsOvacg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB1784938EAF870F2F45CF0CC8BF650BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 17:48:50.0209
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1782
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only
 return values
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB1784938EAF870F2F45CF0CC8BF650BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

all these are good points not to commit BC breaks in hurry.

________________________________
From: Joe Watkins <pthreads@pthreads.org>
Sent: Thursday, April 28, 2016 8:41:34 PM
To: Bob Weinand
Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for onl=
y return values

The problem is as Levi explained though Bob, don't we actually require null=
ables/unions for that case ?

Maybe we can move forward now, confident that by the time 7.1 is released w=
e will have one of those things ?

The problems with that are, the RFC's for unions/intersections don't match =
the implementation, and none of us have a good idea how to implement the RF=
Cs.

In addition, nobody can agree which nullable types RFC should go to vote, o=
r how the whole nullable type question should be resolved.

Cheers
Joe


On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand <bobwei9@hotmail.com<mailto:bo=
bwei9@hotmail.com>> wrote:

> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmitry@zend.com<mailto:dmit=
ry@zend.com>>:
>
> Hi,
>
> The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1db=
fecd28f20477b511
>
> Author: Joe Watkins <krakjoe@php.net<mailto: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<mailto:morrison.levi@gmail.com> <morrison.l=
evi@gmail.com<mailto:morrison.levi@gmail.com>> on behalf of Levi Morrison <=
levim@php.net<mailto: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 val=
ues
>
> 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... 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 N=
EWS entry there.

Thanks,
Bob


--_000_BY2PR0201MB1784938EAF870F2F45CF0CC8BF650BY2PR0201MB1784_--