On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins <pthre...@pthreads.org> 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 <le...@php.net> wrote:
>>
>> On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>> > your Nullable RFC doesn't propose working implementation.
>> >
>> > ________________________________________
>> > From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of
>> > Levi Morrison <le...@php.net>
>> > 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 <dmi...@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.
>> >
>> > 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

Reply via email to