Re: Request to withdraw RFC's for nullable types for only return values
| From: | Dmitry Stogov | Date: | Thu, 28 Apr 2016 17:28:59 +0000 |
| Subject: | Re: Request to withdraw RFC's for nullable types for only return values | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92874@lists.php.net to get a copy of this message | ||
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 union 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 values
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<mailto: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<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
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