On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov <nikita....@gmail.com> wrote:
> I have now made the following changes to the RFC: > > * Removed enable_dl deprecation. The fact that dl() is currently available > by default on CGI, which is a server SAPI, makes this more dicey and needs > more careful consideration. As this RFC needs to go to vote today, I'm > going with the conservative option of dropping it from the RFC. > * Removed register_argc_argv change from the RFC. This was not really a > deprecation, so does not belong here. We'll likely just want to make the > necessary changes in PHP 8. > * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have been > warning since forever, so going through an additional deprecation phase > makes no sense. I went ahead and removed them in PHP 8. > * For the deprecation of implode() with inverted parameter order, > explicitly point out that the single-argument form is not deprecated. > * Various text improvements that do not change the content of the RFC. > > I will start voting on this RFC later today so we make feature freeze. > Nikita, Kalle, None of my feedback was even responded to. There's something fundamentally flawed in the way deprecations are being treated. If there's no compelling case to deprecate, we shouldn't deprecate - it's that simple. Someone's (or even many people's) opinion about the standard library is not a compelling reason. That can be a reason not to add something new - but absolutely not to remove existing functionality and break users' code. convert_cyr_string(), hebrev() and hebrevc() shouldn't even be considered for deprecation. They don't clear the most basic requirement for deprecation - which is having some sort of negative impact to keeping them / positive impact from removing them. There is none. It shouldn't even be up for a vote. is_writeable() should also be removed from the list as contrary to the premise of the RFC, it is not a spelling mistake ( https://en.wiktionary.org/wiki/writeable / https://www.dictionary.com/browse/writeable). Even if it was - it's hardly sufficient enough a reason to deprecate it. There's zero, absolute zero upside from deprecating it, so it doesn't clear the basic requirement for deprecation. This one is probably the least important one from the list since the fix is easy (unlike the ones above - where it's anywhere between a small and very big headache). Still, it's based on a bogus premise and there's simply no reason to do it. Why are we proactively making the lives of users more difficult for literally no gain at all? Zeev
