The problem is as Levi explained though Bob, don't we actually require
nullables/unions for that case ?
Maybe we can move forward now, confident that by the time 7.1 is released
we 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
RFCs.
In addition, nobody can agree which nullable types RFC should go to vote,
or how the whole nullable type question should be resolved.
Cheers
Joe
On Thu, Apr 28, 2016 at 6:36 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
> > Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmi...@zend.com>:
> >
> > Hi,
> >
> > The BC break in PHP-7.0 was introduced by commit
> ee9a78a033696ff9546fb1dbfecd28f20477b511
> >
> > Author: Joe Watkins <krak...@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.l...@gmail.com <morrison.l...@gmail.com> on behalf of
> Levi Morrison <le...@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
> 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
>
> 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
> NEWS entry there.
>
> Thanks,
> Bob
