Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.163 as permitted sender)
Message-ID: <BLU436-SMTP221D8DB5AE7628793251F1AE2650@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <BY2PR0201MB178486D1A9DE2D597C522289BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 28 Apr 2016 19:47:35 +0200
CC: Joe Watkins <pthreads@pthreads.org>,
 Levi Morrison <levim@php.net>,
 internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAFMT4NpBi80uJ-_-==4Wd5h87k=fq3h7N9ygph1kCHg9Czc_Kw@mail.gmail.com> <BY2PR0201MB17848D27325287FFD9785771BF650@BY2PR0201MB1784.namprd02.prod.outlook.com> <CAL=_i_kYSCeRzr15fRJRAjN3LBiqJQbUNz=sNYGCs5B3WgLMqQ@mail.gmail.com> <BY2PR0201MB178486D1A9DE2D597C522289BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values
From: bobwei9@hotmail.com (Bob Weinand)


> Am 28.04.2016 um 19:28 schrieb Dmitry Stogov <dmitry@zend.com>:
>=20
> hi Joe,
>=20
>=20
> No problem, great it's fixed before 7.0.6 release.
>=20
> I think this change might be introduced only together with nullable or =
union types.
>=20
> 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.
>=20
>=20
> Thanks. Dmitry.
>=20
>=20
> ________________________________
> 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 values
>=20
> Evening Dmitry,
>=20
> This was discussed at length with bob, and I think nikita also, it =
seemed like a bug fix rather than a feature.
>=20
> Happy for it to be moved into 7.1 ... sorry for dropping the ball =
there ...
>=20
> Cheers
> Joe
>=20
> On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov =
<dmitry@zend.com<mailto:dmitry@zend.com>> wrote:
> Thanks for catching the BC break.
> Fortunately, we didn't release 7.0.6 with this problem.
>=20
> I see some sense in introducing that check, but changing behaviour =
requires RFC and definitely not allowed in minor versions.
>=20
> 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 =
additional question.
>=20
> Thanks. Dmitry.
>=20
> ________________________________________
> From: morrison.levi@gmail.com<mailto:morrison.levi@gmail.com> =
<morrison.levi@gmail.com<mailto:morrison.levi@gmail.com>> on behalf of =
Levi Morrison <levim@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 =
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

Uhm =E2=80=A6 reading this, it sounds like it was intentional =E2=80=A6 =
if yes, then sorry.

But it still allows an easy fix, just pass the value explicitly.
I think we should leave the fix in 7.1 thus.

The bug itself - violating LSP - must be fixed. The only reason why it's =
fine in 7.0 is BC. But it definitely MUST be fixed in 7.1.

Bob=