On Fri, Jul 24, 2020 at 4:50 PM Bob Weinand <bobw...@hotmail.com> wrote:

> > Am 24.07.2020 um 16:11 schrieb Benjamin Eberlei <kont...@beberlei.de>:
> >
> > On Fri, Jul 24, 2020 at 4:00 PM Chris Riley <t.carn...@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

Reply via email to