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