Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

More or less right. It's easy to archive the "right" goal, if you own the both 
football teams.


From: Tom Worster 
Sent: Thursday, April 28, 2016 11:40:53 PM
To: Levi Morrison; Dmitry Stogov
Cc: internals
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

Levi,

>From one reasonable point of view, Union and Nullable are in conflict with
each other. If one prefers Union then one might argue in favor of Union
over related but different proposals. When it comes to the vote, it's
difficult to support both except with the argument that "I can settle for
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would *either* abandon Union (for
7.1) and throw your support behind Nullable *or* disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom


On 4/28/16, 3:16 PM, "Dmitry Stogov"  wrote:

>Levi, I provided an implementation for your RFC on February 2015, and I
>would be glad if your RFC was accepted that time.
>Bit since that time you block it in respect to "Union Types"
>
>See conversation at PR https://github.com/php/php-src/pull/1045
>
>I would be also glad if your "Nullable Types" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com  on behalf of Levi
>Morrison 
>Sent: Thursday, April 28, 2016 10:02:20 PM
>To: Dmitry Stogov
>Cc: Joe Watkins; internals; Tom Worster
>Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types
>for only return values
>
>On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov  wrote:
>> Levi, I don't understand, why do you keep trying to own "Nullable
>>Types" RFC, if you like completely different "Union Types".
>
>I don't understand; I wrote the RFC. What do you mean, "keep trying to
>own" it? I wrote both Nullable Types and Union Types. Some view those
>RFC's as competing, but they can also be orthogonal. I see the value
>in having both.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Tom Worster]

Levi,

>From one reasonable point of view, Union and Nullable are in conflict with
each other. If one prefers Union then one might argue in favor of Union
over related but different proposals. When it comes to the vote, it's
difficult to support both except with the argument that "I can settle for
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would *either* abandon Union (for
7.1) and throw your support behind Nullable *or* disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom


On 4/28/16, 3:16 PM, "Dmitry Stogov"  wrote:

>Levi, I provided an implementation for your RFC on February 2015, and I
>would be glad if your RFC was accepted that time.
>Bit since that time you block it in respect to "Union Types"
>
>See conversation at PR https://github.com/php/php-src/pull/1045
>
>I would be also glad if your "Nullable Types" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com  on behalf of Levi
>Morrison 
>Sent: Thursday, April 28, 2016 10:02:20 PM
>To: Dmitry Stogov
>Cc: Joe Watkins; internals; Tom Worster
>Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types
>for only return values
>
>On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov  wrote:
>> Levi, I don't understand, why do you keep trying to own "Nullable
>>Types" RFC, if you like completely different "Union Types".
>
>I don't understand; I wrote the RFC. What do you mean, "keep trying to
>own" it? I wrote both Nullable Types and Union Types. Some view those
>RFC's as competing, but they can also be orthogonal. I see the value
>in having both.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Björn Larsson]

Hi,

Can't resist jumping into this discussion, but when I first read
both RFC's, I found them quite complementary. I was actually a
bit tempted to combine them into one just as a writing exercise
for my self (wanted to train on writing RFC's).

My suggestion would be that you merge them into one and put
it into vote quickly, maybe having you both as authors or one of
you taking the lead? And again, sorry if I jump into the discussion
uninvited.

/Regards //Björn Larsson/

Den 2016-04-28 kl. 21:16, skrev Dmitry Stogov:

Levi, I provided an implementation for your RFC on February 2015, and I would 
be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"

See conversation at PR https://github.com/php/php-src/pull/1045

I would be also glad if your "Nullable Types" RFC was accepted now, but I don't 
trust in your intention to support it.


From: morrison.l...@gmail.com  on behalf of Levi Morrison 

Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov  wrote:

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like 
completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Levi, I provided an implementation for your RFC on February 2015, and I would 
be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"

See conversation at PR https://github.com/php/php-src/pull/1045

I would be also glad if your "Nullable Types" RFC was accepted now, but I don't 
trust in your intention to support it.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov  wrote:
> Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, 
> if you like completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Levi Morrison]

On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov  wrote:
> Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, 
> if you like completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, 
if you like completely different "Union Types".


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 9:47:18 PM
To: Joe Watkins
Cc: Dmitry Stogov; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for 
only return values

On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins  wrote:
> Levi,
>
> Why do you need to block Dmitry's return type nullable RFC ?
>
> We need to move forward, that has an implementation, ready for a long
> time, doesn't seem to block nullable parameter types rfc, either separately
> or as part of unions.
>
> So, I'm not understanding why you need to hold up Dmitry any more.
>
> Please, explain.
>
> Cheers
> Joe
>
> On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:
>>
>> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov  wrote:
>> > your Nullable RFC doesn't propose working implementation.
>> >
>> > 
>> > From: morrison.l...@gmail.com  on behalf of
>> > Levi Morrison 
>> > Sent: Thursday, April 28, 2016 8:39:03 PM
>> > To: Dmitry Stogov
>> > Cc: internals; Tom Worster
>> > Subject: Re: Request to withdraw RFC's for nullable types for only
>> > return values
>> >
>> > On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.
>> >
>> > In that case: are you fine with my RFCs going to vote first (and
>> > soon)? We presently have four somewhat competing RFCs and need to work
>> > out voting order.
>> >
>> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>>
>> It doesn't have an implementation, sure. But you already worked out
>> return types, the basics are already there in parameter types and
>> there's an implementation in HHVM. Do you really think this would be a
>> blocker? There is no reason to believe that a short-hand nullable
>> types implementation cannot be reasonably done.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Levi Morrison]

On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins  wrote:
> Levi,
>
> Why do you need to block Dmitry's return type nullable RFC ?
>
> We need to move forward, that has an implementation, ready for a long
> time, doesn't seem to block nullable parameter types rfc, either separately
> or as part of unions.
>
> So, I'm not understanding why you need to hold up Dmitry any more.
>
> Please, explain.
>
> Cheers
> Joe
>
> On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:
>>
>> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov  wrote:
>> > your Nullable RFC doesn't propose working implementation.
>> >
>> > 
>> > From: morrison.l...@gmail.com  on behalf of
>> > Levi Morrison 
>> > Sent: Thursday, April 28, 2016 8:39:03 PM
>> > To: Dmitry Stogov
>> > Cc: internals; Tom Worster
>> > Subject: Re: Request to withdraw RFC's for nullable types for only
>> > return values
>> >
>> > On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.
>> >
>> > In that case: are you fine with my RFCs going to vote first (and
>> > soon)? We presently have four somewhat competing RFCs and need to work
>> > out voting order.
>> >
>> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>>
>> It doesn't have an implementation, sure. But you already worked out
>> return types, the basics are already there in parameter types and
>> there's an implementation in HHVM. Do you really think this would be a
>> blocker? There is no reason to believe that a short-hand nullable
>> types implementation cannot be reasonably done.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Joe Watkins]

Levi,

Why do you need to block Dmitry's return type nullable RFC ?

We need to move forward, that has an implementation, ready for a long
time, doesn't seem to block nullable parameter types rfc, either separately
or as part of unions.

So, I'm not understanding why you need to hold up Dmitry any more.

Please, explain.

Cheers
Joe

On Thu, Apr 28, 2016 at 6:47 PM, Levi Morrison  wrote:

> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov  wrote:
> > your Nullable RFC doesn't propose working implementation.
> >
> > 
> > From: morrison.l...@gmail.com  on behalf of
> Levi Morrison 
> > Sent: Thursday, April 28, 2016 8:39:03 PM
> > To: Dmitry Stogov
> > Cc: internals; Tom Worster
> > Subject: Re: Request to withdraw RFC's for nullable types for only
> return values
> >
> > On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.
> >
> > In that case: are you fine with my RFCs going to vote first (and
> > soon)? We presently have four somewhat competing RFCs and need to work
> > out voting order.
> >
> > Tom: are you willing to withdraw or wait for my RFCs to vote first?
>
> It doesn't have an implementation, sure. But you already worked out
> return types, the basics are already there in parameter types and
> there's an implementation in HHVM. Do you really think this would be a
> blocker? There is no reason to believe that a short-hand nullable
> types implementation cannot be reasonably done.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

I'm not happy with the fact, that you propose two competing RFCs, support only 
one and trying to withdraw other competitors.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 8:47:41 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov  wrote:
> your Nullable RFC doesn't propose working implementation.
>
> 
> From: morrison.l...@gmail.com  on behalf of Levi 
> Morrison 
> Sent: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: internals; Tom Worster
> Subject: Re: Request to withdraw RFC's for nullable types for only return 
> values
>
> On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.
>
> In that case: are you fine with my RFCs going to vote first (and
> soon)? We presently have four somewhat competing RFCs and need to work
> out voting order.
>
> Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Levi Morrison]

On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov  wrote:
> your Nullable RFC doesn't propose working implementation.
>
> 
> From: morrison.l...@gmail.com  on behalf of Levi 
> Morrison 
> Sent: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: internals; Tom Worster
> Subject: Re: Request to withdraw RFC's for nullable types for only return 
> values
>
> On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.
>
> In that case: are you fine with my RFCs going to vote first (and
> soon)? We presently have four somewhat competing RFCs and need to work
> out voting order.
>
> Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Bob Weinand]

> Am 28.04.2016 um 19:28 schrieb Dmitry Stogov :
> 
> 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 
> 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 
> > 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.l...@gmail.com 
> > on behalf of Levi 
> Morrison >
> 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.
> 
>  
> 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:
> 
>  
> 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
> 

Uhm … reading this, it sounds like it was intentional … 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

your Nullable RFC doesn't propose working implementation.


From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Levi Morrison]

On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov  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.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

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 
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 
> 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.l...@gmail.com 
> on behalf of Levi 
Morrison >
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.



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:



(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

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Joe Watkins]

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  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.l...@gmail.com  on behalf of Levi
> Morrison 
> 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.
>
> 
> 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:
>
> 
> 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
>

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

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.l...@gmail.com  on behalf of Levi 
Morrison 
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.



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:



(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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

[Dmitry Stogov]

Hi,

The BC break in PHP-7.0 was introduced by commit 
ee9a78a033696ff9546fb1dbfecd28f20477b511 

Author: Joe Watkins 
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  on behalf of Levi 
Morrison 
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.



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:



(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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php