Re: [RFC][Proposal] Renamed parameters

On Fri, Jul 24, 2020 at 4:50 PM Bob Weinand <bobwei9@hotmail.com> wrote: > > Am 24.07.2020 um 16:11 schrieb Benjamin Eberlei <kontakt@beberlei.de>: > > > > On Fri, Jul 24, 2020 at 4:00 PM Chris Riley <t.carnage@gmail.com> wrote: > > > >> Hi all, > >> > >> Following up from this I've created a draft RFC: > >> https://wiki.php.net/rfc/renamed_parameters will move > >> to in discussion > >> once > >> I've ensured everything important has been captured. > >> > >> Regards, > >> Chris > >> > > > > You added PHP 8.0 as a propsoed version, but that will not be possible > > anymore 2 weeks of discussion + 2 weeks of voting are not possible to fit > > in before the feature freeze, which is in 11 days. > > Hey Benjamin, > > While you are technically correct, the primary point of a feature freeze > is not allowing in completely new features. > It will always happen that there are changes and extensions to RFCs > introduced for the next version which may need to be addressed first, > because there is massive benefit to the new feature in that case. (from a > backwards/forwards compatibility standpoint for example) > > I do not necessarily agree with the RFC (not given it much thought yet), > but I think such RFCs shall still be able to be introduced later on (well, > not in RC phase, but a bit after the feature freeze cutoff), if there is > actual benefit from them not being deferred to the next version. > Ultimately, the RM has to make the call (also to avoid indefinite delays or > filibustering or such). > We should of course be open to making minor adjustments due to unanticipated issues after feature freeze -- after all, that's where we gain experience with new features. The emphasis here is very much on *minor* and *unanticipated* though. None of the issues this RFC tries to address, or even the approaches it suggests, are new. This has already been discussed during the main proposal -- and not just as a side mention, this was the core controversy of the named parameters proposal. I am open to discussing minor amendments like Benjamin's suggestion for a parameter alias attribute, if we think it important to introduce it in PHP 8.0 rather than at a later time. But making a switch to opt-in named parameters? That's essentially a completely different feature and we certainly cannot accept such a fundamental change past feature freeze. Regards, Nikita