Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111175
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWy4C0ng5SnEBM6SybcyvO0+MPiHcVcEvDrFG4fNsf2Opw@mail.gmail.com>
 <CAEPJdu=H1j4C8TvdQF=dbMSKUUM=1-3hVkPf1f3WU-hZgKiy8A@mail.gmail.com> <VI1PR02MB4703F7E73D33AF4390337E6DE2770@VI1PR02MB4703.eurprd02.prod.outlook.com>
In-Reply-To: <VI1PR02MB4703F7E73D33AF4390337E6DE2770@VI1PR02MB4703.eurprd02.prod.outlook.com>
Date: Fri, 24 Jul 2020 17:10:12 +0200
Message-ID: <CAF+90c_SY8Hd5ChPM+EtDU6JZgBCjHOYvSq81QHpz9eLnXSDRA@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Chris Riley <t.carnage@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a8c1b05ab315ff1"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000009a8c1b05ab315ff1
Content-Type: text/plain; charset="UTF-8"

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

--0000000000009a8c1b05ab315ff1--