Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB17848D27325287FFD9785771BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4NpBi80uJ-_-==4Wd5h87k=fq3h7N9ygph1kCHg9Czc_Kw@mail.gmail.com>
	<BY2PR0201MB17848D27325287FFD9785771BF650@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Thu, 28 Apr 2016 18:20:12 +0100
Message-ID: <CAL=_i_kYSCeRzr15fRJRAjN3LBiqJQbUNz=sNYGCs5B3WgLMqQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>, Tom Worster <fsb@thefsb.org>
Content-Type: multipart/alternative; boundary=001a1143312c3753c705318ebdf8
Subject: Re: Request to withdraw RFC's for nullable types for only return values
From: pthreads@pthreads.org (Joe Watkins)

--001a1143312c3753c705318ebdf8
Content-Type: text/plain; charset=UTF-8

Evening Dmitry,

This was discussed at length with bob, and I think nikita also, it seemed
like 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> 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
> additional question.
>
> Thanks. Dmitry.
>
> ________________________________________
> From: morrison.levi@gmail.com <morrison.levi@gmail.com> on behalf of Levi
> Morrison <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
>
> 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 = null);
> }
>
> class Hello implements Foo {
>     public function bar(array $baz = 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 = [])  {}
> }
>
> ?>
>
> (or a short-form `?array $baz = []` 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=72119
>   [2]: https://wiki.php.net/rfc/union_types
>   [2]: https://wiki.php.net/rfc/nullable_types
>

--001a1143312c3753c705318ebdf8--