# [RFC] Deprecations for 7.4

- Thread: https://externals.io/message/106012
- Original archive: https://news-web.php.net/php.internals/106012
- Started by Kalle Sommer Nielsen on 2019-06-21T15:20:08+00:00
- Messages: 34
- RFC: Deprecations for PHP 7.4 (Implemented (PHP 7.4)) — https://externals.io/rfc/deprecations_php_7_4.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/106012.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #106012 — Kalle Sommer Nielsen — 2019-06-21T15:20:08+00:00

URL: https://externals.io/message/106012#106012

Greetings Internals

Nikita and I would like to open the discussion for the RFC:
"Deprecations for 7.4", this RFC targets a larger set of various
features targeting for deprecation in 7.4 with the intention of
removal in PHP 8.0.

https://wiki.php.net/rfc/deprecations_php_7_4

If there is no major objections to this RFC, then voting will begin in
a 2 weeks time.

Regards,
Nikita & Kalle

---

## #106013 — Rowan Collins — 2019-06-21T16:24:03+00:00

URL: https://externals.io/message/106012#106013

> Greetings Internals
>
> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.
>
> https://wiki.php.net/rfc/deprecations_php_7_4
>


The mention of "convert_cyr_string" here makes me want to revisit the
oft-abused "utf8encode" and "utf8decode" functions. The downside in all
cases is that PHP has no single correct function for encoding conversions,
with mbstring, intl, and iconv all offering slightly different
implementations, and all distributed as optional extensions.

Is there some way we can bless a single conversion function, in core, and
recommend that in deprecation notices?

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #106014 — Theodore Brown — 2019-06-21T16:54:19+00:00

URL: https://externals.io/message/106012#106014

> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.
>
> https://wiki.php.net/rfc/deprecations_php_7_4

It's still unclear what is being proposed for the register_argc_argv
ini directive. When the ini setting is removed, will the `$argv` and
`$argc` variables always be available on CLI SAPIs, and never be
available on non-CLI SAPIs?

If that's the case, I'd propose a deprecation notice in PHP 7.4 when
using `-d register_argc_argv=0` on the command line, and when accessing
the predefined `$argv` or `$argc` variables from non-CLI SAPIs.

Thanks,
Theodore

---

## #106015 — Nikita Popov — 2019-06-21T17:08:29+00:00

URL: https://externals.io/message/106012#106015

On Fri, Jun 21, 2019 at 6:54 PM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Fri, Jun 21, 2019 at 10:20 AM Kalle Sommer Nielsen <kalle@php.net>
> wrote:
>
> > […]
>
> It's still unclear what is being proposed for the register_argc_argv
> ini directive. When the ini setting is removed, will the `$argv` and
> `$argc` variables always be available on CLI SAPIs, and never be
> available on non-CLI SAPIs?
>
> If that's the case, I'd propose a deprecation notice in PHP 7.4 when
> using `-d register_argc_argv=0` on the command line, and when accessing
> the predefined `$argv` or `$argc` variables from non-CLI SAPIs.


I've update the RFC to say that the option will be removed without
deprecation, with argv always available on CLI and never on non-CLI.
Throwing a deprecation warning when accessing $argv in non-CLI SAPIs is too
complicated and/or unreliable.

Nikita

---

## #106016 — Claude Pache — 2019-06-21T17:54:06+00:00

URL: https://externals.io/message/106012#106016

> Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen <kalle@php.net> a écrit :
> 
> Greetings Internals
> 
> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.
> 
> https://wiki.php.net/rfc/deprecations_php_7_4
> 
> If there is no major objections to this RFC, then voting will begin in
> a 2 weeks time.
> 
> Regards,
> Nikita & Kalle
> 
> -- 
> 
> 
> 

I object to the following deprecations:

------------

apache_request_headers(). 

The function has that name because once upon a time it was available only when PHP run as an Apache module. But although it (and its irregularly-named alias `getallheaders()`) is now available somewhere else, the functionality has not changed for those that run PHP as an Apache module.

Also, according to the documentation, another function, `apache_response_headers()`, is also available to other SAPIs. However, it has the benefit of not having a documented alias, so that it can escape the deprecation proposal?

Note also the existence of `nsapi_request_headers()` function that (according to the documentation) does the same thing than `getallheaders()` when PHP runs as a NSAPI module.

And last but not least, `*_request_headers()`is more precisely named than `getallheaders()` (given the existence of `*_response_header()` functions).

------------
   
 `is_writeable()`. 

That “writeable” is “a spelling mistake” (as opposed to an “uncommon alternative spelling”) is an opinion that is not really proveable.

------------

—Claude

---

## #106017 — Bishop Bettini — 2019-06-21T18:15:46+00:00

URL: https://externals.io/message/106012#106017

>
>
> > […]
>
> I object to the following deprecations:
>
> ------------
>
> `is_writeable()`.
>
> That “writeable” is “a spelling mistake” (as opposed to an “uncommon
> alternative spelling”) is an opinion that is not really probable.
>

Agreed.

http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html

"With this in mind, what about "writable" and its variant "writeable"?
While the dictionary says "writable" is correct, I consider that spelling
harmful.  Search for "table" and you'll hit "wri*table*", which is
undoubtedly a false positive."

---

## #106018 — Claude Pache — 2019-06-21T18:46:04+00:00

URL: https://externals.io/message/106012#106018

> Le 21 juin 2019 à 20:15, Bishop Bettini <bishop@php.net> a écrit :
> 
> 
> 
> 
> > […]
> 
> I object to the following deprecations:
> 
> ------------
> 
> `is_writeable()`. 
> 
> That “writeable” is “a spelling mistake” (as opposed to an “uncommon alternative spelling”) is an opinion that is not really probable.
> 
> Agreed.
> 
> http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html <http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html>
> 
> "With this in mind, what about "writable" and its variant "writeable"?  While the dictionary says "writable" is correct, I consider that spelling harmful.  Search for "table" and you'll hit "writable", which is undoubtedly a false positive."

Your spell checker has incorrectly “fixed” the last word of my message... —Claude

---

## #106019 — Bishop Bettini — 2019-06-21T18:50:01+00:00

URL: https://externals.io/message/106012#106019

>
>
> > […]
> <mailto:claude.pache@gmail.com>> wrote:
> > […]
> kalle@php.net>> a écrit :
> > […]
> https://wiki.php.net/rfc/deprecations_php_7_4>
> > […]
> alternative spelling”) is an opinion that is not really probable.
> > […]
> http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html>
> > […]
> While the dictionary says "writable" is correct, I consider that spelling
> harmful.  Search for "table" and you'll hit "writable", which is
> undoubtedly a false positive."
>
> Your spell checker has incorrectly “fixed” the last word of my message...
> —Claude
>

The irony's not lost on me. Yet, apologies: human error. I manually typed
it, as I was working on my mobile and deleted whilst replying.
s/probable/provable/g.

---

## #106020 — Stanislav Malyshev — 2019-06-21T23:04:27+00:00

URL: https://externals.io/message/106012#106020

Hi!

> Nikita and I would like to open the discussion for the RFC:
> "Deprecations for 7.4", this RFC targets a larger set of various
> features targeting for deprecation in 7.4 with the intention of
> removal in PHP 8.0.

My first question for many of those is - why? I.e. it deprecates a bunch
of niche functions. Most people do not use these functions, so they
probably don't care. Those they do use them would find their code broken
or produce new warnings and needs to be changed. I have hard time
identifying whose life would be made better by these changes.

Now, if some of these functions are hopelessly broken or have no valid
use cases - like magic quotes - then phasing them out makes sense, and
the audience whose life can be made better are people who use those
unaware of them being broken, or plan to use them and would thus have
broken code unless we warn them (or remove the functions, eventually).

But for functions that work just fine, I see absolutely no reason to
introduce friction without any apparent upside.

For the specifics, I think things like removing allow_url_include
requires separate RFC. It's a serious functionality change, and bundling
it with 20 or so other changes would not allow to properly consider it.
In general mass-change RFCs usually are not very conductive to properly
discussing each specific change, but mixing changes of different types
makes it even worse.

Same probably holds for "Unbinding $this from non-static closures" but
for different reasons - this looks like a consistency change which is
necessary to bring Closure in compliance with the rest of the engine. If
non-$this call is not supported in PHP 8, then bindTo(null) should
produce an error, not sure it even needs an RFC for that.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #106021 — Stanislav Malyshev — 2019-06-21T23:08:46+00:00

URL: https://externals.io/message/106012#106021

Hi!

> I've update the RFC to say that the option will be removed without
> deprecation, with argv always available on CLI and never on non-CLI.
> Throwing a deprecation warning when accessing $argv in non-CLI SAPIs is too
> complicated and/or unreliable.

So this means CGI binary would not have $argv? AFAIK it has it set now.
What about phpdbg and embed SAPI? Or do you mean CLI/non-CLI some more
subtle distinction then just "cli" SAPI?

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #106022 — Kalle Sommer Nielsen — 2019-06-22T07:22:48+00:00

URL: https://externals.io/message/106012#106022

Hi
Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <smalyshev@gmail.com>:
> My first question for many of those is - why? I.e. it deprecates a bunch
> of niche functions. Most people do not use these functions, so they
> probably don't care. Those they do use them would find their code broken
> or produce new warnings and needs to be changed. I have hard time
> identifying whose life would be made better by these changes.
>
> Now, if some of these functions are hopelessly broken or have no valid
> use cases - like magic quotes - then phasing them out makes sense, and
> the audience whose life can be made better are people who use those
> unaware of them being broken, or plan to use them and would thus have
> broken code unless we warn them (or remove the functions, eventually).
>
> But for functions that work just fine, I see absolutely no reason to
> introduce friction without any apparent upside.

While I understand where you are coming from on this, I do think that
functionality that is better supported by dedicated extensions to do
the job instead of providing some functions in the standard library
that converts from a few specific encodings to another:

convert_cyr_string() -- This uses a non standard set of encoding names
and only for cyrillic like encodings, what justifications is there for
keeping this in the standard library over using ext/intl with
UConverter that supports a much larger set of encodings in a much more
generic way for more than just cyrillic encodings?

 `hebrev()`, hebrevc() -- These functions were designed for the web era
pre IE6 where some browsers did not support <html dir="rtl"
lang="he">, what use case is there for these now that the web has
evolved so much in the past two decades since these were added to do
this on a backend?

One of the biggest complaints we have in regards to the standard
library is that it is inconsistent, it provides very niche
functionality that is better supported elsewhere. I think it is a
perfect opportunity to review these legacy blocks and direct users to
better alternatives instead of us having to support many ways of doing
the same thing. Why should the standard library support only a subset
of conversion functionality that is so niche and already supported
much more fluently and abstract in extensions dedicated for the
matter. I personally think that is a very valid reason to consider
these functions for deprecations.

We have a large set of aliases that easily can make the standard
library feel convoluted and therefore also creates a certain technical
depth as a side-effect. The cost of having to convert these functions
is a small price to allow the language to evolve in my honest opinion.

> For the specifics, I think things like removing allow_url_include
> requires separate RFC. It's a serious functionality change, and bundling
> it with 20 or so other changes would not allow to properly consider it.
> In general mass-change RFCs usually are not very conductive to properly
> discussing each specific change, but mixing changes of different types
> makes it even worse.

I will have a chat with Nikita regarding this.



-- 
regards,

Kalle Sommer Nielsen
kalle@php.net

---

## #106023 — Joe Watkins — 2019-06-22T07:44:25+00:00

URL: https://externals.io/message/106012#106023

Just a note on process.

It is not necessary to hold multiple RFC's:

> For procedural reasons, multiple RFCs may be combined into one, in which
case there may be multiple primary votes.
> Combining multiple RFCs into one does not allow turning a primary vote
into a secondary vote.

In general, something is considered a primary vote if it could be conducted
independently of other primary votes in the same RFC - ie, it is not an
implementation detail.

So, what we have here is multiple primary votes ...

[1] https://wiki.php.net/rfc/voting

Cheers
Joe





> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalyshev@gmail.com>:
> > […]
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>
> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>
> `hebrev()`, hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support <html dir="rtl"
> lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>
> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
>
> > […]
>
> I will have a chat with Nikita regarding this.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net

---

## #106024 — Claude Pache — 2019-06-22T10:41:45+00:00

URL: https://externals.io/message/106012#106024

> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen <kalle@php.net> a écrit :
> 
> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <smalyshev@gmail.com>:
> > […]
> 
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
> 
> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
> 
> `hebrev()`, hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support <html dir="rtl"
> lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
> 
> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
> 
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
> 

PHP has indeed a sheer number of old-school functions and of niche functions, but as developer, they don’t bother me as long as I don’t see them.

One occasion where I am bothered, because I see them, is when I explore the manual in order to find a function that does some job. Let’s take for example the Session Functions:

https://www.php.net/manual/en/ref.session.php <https://www.php.net/manual/en/ref.session.php>

In the Table of Contents, functions that are actually useful (e.g., `session_start()`) are intermixed with legacy functions that relate to some obsolete way to handle session variables (e.g. `session_register()`).

For the particular case of Session functions, there is *some* progress since few years ago (the days of PHP 5.2), because obsolete functions are clearly marked as such on their individual documentation page (https://www.php.net/manual/en/function.session-register.php <https://www.php.net/manual/en/function.session-register.php>; although the pink Warning box ought to be at the very top of the page, so I’m not in danger to actually read the documentation before realising that it is obsolete). But the Table of Contents still needs to be reorganised...


Now, let’s take the manual of String Functions:

https://www.php.net/manual/en/ref.strings.php <https://www.php.net/manual/en/ref.strings.php>

Those may be separated in two groups: the first one for those that are recommended/useful for modern code, and the second one for legacy functions such as `convert_cyr_string()` and `hebrevc()` that provide functionality that are hardly useful today or that are better handled by some other mean.

Moreover, for each of those functions, a pink Warning box might be placed at the very top of their documentation page, stating that such function is probably not useful or recommended for new or refactored code, and pointing to better alternatives when appropriate.

*However*, such documentation improvement, does *not* imply throwing a deprecation warning each time the functionality is used. There is no issue for legacy code base to continue to use it as long as it is not broken, and as long as I don’t see it.

—Claude

---

## #106025 — Zeev Suraski — 2019-06-22T10:43:46+00:00

URL: https://externals.io/message/106012#106025

> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalyshev@gmail.com>:
> > […]
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>

Kalle,

I see very few ways in which you'd be able to convince anybody whose code
was impacted by these removals that they're better off having to audit
their code and learn new library semantics - instead of, well, doing
nothing.

I view this in the same trend as the deprecation of short_tags -
deprecations that may make us feel good, make for a 'more proper' code
base, and bring hassle to our userbase while aiding absolutely no-one in
the process.


> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>

Simple - it harms nobody to keep it, and removing it aids nobody.


> `hebrev()`, hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support <html dir="rtl"
> lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>

I've seen `hebrev()` used as recently as a couple of years ago and given that
I'm not very active in the local community - it's probably still being used
in all sorts of use cases when interacting with old legacy systems (e.g.
IBM i).  How are you assuming it's not in use?

One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere.


While I've heard the former complaint very frequently (and I agree with it
entirely), I've quite literally *never* heard the latter complaint.  Not
once.  Niche functionality doesn't bug anybody.  Inconsistent core
functionality bugs mostly everyone.  Bundling the two as if they're the
same, or even similar - is wrong.  Niche functionality isn't in the way of
anybody - and while it's mostly of no use for most people, the few people
who do need it would often be remarkably thankful for finding it available
(hebrev() certainly falls in that category).  These functions have zero
negative footprint - they consume virtually no memory, they don't slow
anything down, and I'd feel very confident arguring they do not pollute the
namespace in any meaningful way (if anybody here ever bumped into someone
that was upset about `hebrev()` being taken, please raise your hand).

Instead of removing functionality that most find useless but some found
invaluable - why don't we introduce a new extension, 'legacy', that will
include these functions?  It can even be disabled by default.  That way we
don't needlessly and pointlessly make the upgrade path more difficult - or
at least, we make it just marginally so (you'd be able to eliminate a class
of needless compatibility breakages that would otherwise send you auditing
and researching new ways to do exactly the same thing - by simply turning
on an extension).

I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
>

Again, I think our standard library certainly suffers from defficiencies -
but I have a hard time accepting that niche functions is anywhere near the
top of that list, or that it's even on it to begin with.

The key problems of our standard libraries are inconsistencies in naming,
inconsistencies in argument definitions and sometimes inconsistencies in
behavior.

Personally, I think we should actually consider tackling these with a newly
designed standard library that would be available via a new top level
namespace - *without* interfering with the existing one - which perhaps we
can then deprecate by 2030.  That would actually bring tremendous value to
end users, unlike some of these deprecations.

To summarize:
1.  Reconsider the proposal to deprecate useful (albeit niche) functions
like convert_cyr_string(), `hebrev()`, money_format() and others..  These
deprecations bring virtually zero value but very non-zero headache to
affected users.   I've yet to bump into a single person, ever, that told me
how happy they were with version X.Y deprecating feature Z. Complaints?
That's a different story.
2.  In case you do want to move forward with them - consider moving them to
a new 'legacy' extension instead of outright removing them.  Perhaps this
can be a solution for short_tags as well, and it can also be a longer-term
compromise between the motivation to 'clean up' the language, and the
hassle it inflicts on our users when they want to upgrade (which results in
longer upgrade cycles and consequently worse security overall).
3.  I think we'd all be better off focusing on the real deffficiencies of
our standard library.  Deprecating's easy, but it's also not very useful.
If we can introduce a new, fixed standard library in PHP 8 - it can be a
game changer.

Thanks,

Zeev

---

## #106027 — Andrey Andreev — 2019-06-22T12:23:54+00:00

URL: https://externals.io/message/106012#106027

Hi,

With regards to the `array_key_exists()` deprecation, the RFC currently
says nothing about things like ArrayAccess and object properties that
contain arrays. I'm sure that these are exceptions that aren't meant
to be deprecated, but can you please specify that explicitly? We all
know how little bits like that can result in awful outcomes.

Also, it's unclear to me why `get_called_class()` should be deprecated.
While the rest of the listed deprecations have either motivation
written for them or are self-evidently legacy functionalities that
nobody should be using today, this one seems to be just a case of
"let's not have more than one way of doing things" and I'm not really
a fan of that.

Cheers,
Andrey.

---

## #106028 — Nikita Popov — 2019-06-22T12:58:58+00:00

URL: https://externals.io/message/106012#106028

> Hi,
>
> With regards to the `array_key_exists()` deprecation, the RFC currently
> says nothing about things like ArrayAccess and object properties that
> contain arrays. I'm sure that these are exceptions that aren't meant
> to be deprecated, but can you please specify that explicitly? We all
> know how little bits like that can result in awful outcomes.
>

Thanks for bringing this up: It's a great example of why this needs to be
deprecated. `array_key_exists()` actually has no support for ArrayAccess
objects at all -- it only operates on (mangled) object properties. But just
seeing the name and the fact that it doesn't error when passed an
ArrayAccess object, it's quite easy to jump to the wrong conclusion. I've
updated the RFC to mention this now.

I don't understand what you mean by "object properties that contain arrays"
though, or rather how that related to `array_key_exists()`.

Also, it's unclear to me why `get_called_class()` should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have more than one way of doing things" and I'm not really
> a fan of that.
>

Personally I agree. I don't really see a strong motivation for dropping
this function. Kalle?

Nikita

---

## #106031 — Pieter Hordijk — 2019-06-22T16:10:47+00:00

URL: https://externals.io/message/106012#106031

> Also, it's unclear to me why `get_called_class()` should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have more than one way of doing things" and I'm not really
> a fan of that.

I agree with above. When looking through the list of deprecations this
one jumps out for me as being an outlier too.

Maybe it should just be removed from the RFC?

Pieter

---

## #106032 — Nikita Popov — 2019-06-22T16:58:42+00:00

URL: https://externals.io/message/106012#106032

On Sat, Jun 22, 2019 at 6:11 PM Pieter Hordijk <info@pieterhordijk.com>
wrote:

>
>
> > […]
>
> I agree with above. When looking through the list of deprecations this
> one jumps out for me as being an outlier too.
>
> Maybe it should just be removed from the RFC?


As we all seem to agree on this one (Kalle as well), I went ahead and
dropped it from the RFC.

Nikita

---

## #106033 — Stanislav Malyshev — 2019-06-22T19:31:24+00:00

URL: https://externals.io/message/106012#106033

Hi!

> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:

It may be supported by other extensions (btw did anybody verify that it
actually is and gives the same results?), but this is not the reason per
se to remove old working functions. There's a lot of duplication in
programming languages - all (Turing-complete) languages ultimately do
the same thing, and most practical languages have way more syntax and
utility functions than strictly necessary to achieve desired outcome.
This is because redundancy in expressiveness improves productivity.
Here we have the reverse - we are forcing people who have working code
to go back and rewrite it to essentially achieve the same result we
already have - negative productivity. I don't see a point in doing this.

> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with

It works.

> `hebrev()`, hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support <html dir="rtl"
> lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?

I see multiple references to it in code online. If it works for people
that use it - why touch it? I even see porting it to other languages,
like Javascript. Pretty weird for a function that nobody ever needs,
isn't it?

> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a

I don't see it as a complaint at all. "Library provides many functions"
- this is a *complaint*?! This is pretty much why PHP became popular!
I know there are people online that enjoy writing nitpicky snide
articles about how PHP is "inconsistent". I say - let them. Internet is
big, anybody can write anything, it's not a reason to take to heart
everything random people on the internet write. Satisfying those people
- some of whom aren't even PHP users - is infinitely less important than
the time of actual PHP users that actually use the language. And I do
not see who of the actual PHP users these removals would help.

"Consistency" is only helpful when it improves something and makes work
easier. Nothing is made easier by removing functions that work.

> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.

It is very common in virtually all programming languages to have utility
functions to support special cases, even if there's a library that
supports more generic case. You have your regular expression library,
and then you have functions that parse dates, or numbers, or phone
numbers - even though regex library alone enough to implement those. It
is a very common and standard practice. Moreover, we're not talking
about introducing new functionality here - we're talking about removing
functionality that people *already use in their code*. The bar for this
should be super-high. In fact, excluding clear blunders like magic
quotes, etc. if we never ever removed a working function, I'd be fine
even with that. But if we decide to remove, it should be for reasons far
better than "you can do it with other functions" - that never was the
PHP way and shouldn't be.

> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical

What you call "convoluted" I call "convenient and versatile". Having
many functions to help people do what they need is good. We don't pay
per function. There's no goal to have as few functions as possible.

> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.

I don't see how this is "evolving", if you understand evolving as
getting more fit for the purpose. I do not recognize "having as few
functions as possible" as a goal worth pursuing, so what's the point?

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #106034 — Stanislav Malyshev — 2019-06-22T19:38:17+00:00

URL: https://externals.io/message/106012#106034

Hi!

> In general, something is considered a primary vote if it could be
> conducted independently of other primary votes in the same RFC - ie, it
> is not an implementation detail.
> 
> So, what we have here is multiple primary votes ...

I am not talking bureaucracy here, I'm talking about discussion on the
merits. It is virtually impossible to discuss 20 proposals on the merits
within a single thread. Of course, in this RFC there are not 20
different proposals - most of it is of the same type, deprecating
certain function, usually for the same reason (which I coincidentally
believer is wrong, but that's for another thread).

However, some of these are of a different types, and I think they'd be
better as separate RFCs. Especially the allow_url_include thing and
closure $this thing (which I'm not sure even needs an RFC if I
understand the argument right - we pretty much have no choice there).
Discussing them all together would be messy.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #106036 — Stanislav Malyshev — 2019-06-22T20:21:23+00:00

URL: https://externals.io/message/106012#106036

Hi!

enable_dl - I am not clear what is proposed - to remove `dl()`
functionality in PHP 8 completely, even in CLI? Or to keep it in CLI
always on and remove the directive?
My opinion: drop the directive, let the SAPI decide if `dl()` is possible,
with CLI keeping it. Not sure about embed though. But I guess if
somebody needs it in embed, they probably could patch it so it enables
the `dl()`. Not sure how easy it would be to make this per-SAPI decision
though...

The 'real' type - see no reason to touch it, it doesn't hurt anybody.

hebrev, hebrevc, apache_request_headers, is_writeable,
convert_cyr_string, money_format, restore_include_path - leave them in
peace (argued why in another thread). Maybe legacy extension as Zeev
suggested, I'm fine with that.

Magic quotes and all related - burn with fire. Magic quotes was a
mistake, and here my BC inner voice is not able to say anything in its
favor.

array_key_exists(object) - fine with dropping object behavior. It does
say "array".
And btw, can we actually make it work with ArrayAccess properly?

INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them.
No point in keeping stuff that doesn't work.

register_argc_argv - support making $argc/$argv always available in CLI
but not sure about the definition of CLI. Does CGI qualify? Does embed?
This worries me a bit. Same situation as in `dl()` - it's like we need
some ini setting that is only accessible to SAPIs... Maybe we should
introduce new INI level that is only settable by SAPI but not changeable
later? Just brainstorming here.

Reflection export() - check if any real code is using it. Reflection
printing is kinda-sorta is the area that BC breaks may be acceptable,
since it's unlikely production code paths would depend on it, but we
need to check it. Undecided so far.

mb_strrpos - if we promised to deprecate, we may as well do it.

 `implode()` - leave it alone, yes I know it's weird order, but messing
with it helps nobody. Yes, I know, "inconsistent". Making it
"consistent" will improve the life of exactly 0 people. Please let it be.

ezmlm_hash - undecided... it's really the niche of the niche. It also
doesn't hurt anyone, but not sure if anybody actually using it anymore.

allow_url_include - as I said, needs separate RFC. I am leaning towards
removing it, but maybe there's some use case for it...

Unbinding $this - already wrote about it, doesn't look like we have a
choice there given that what it is trying to do seems not to be
supported in PHP 8. So there may not be a point in even voting on it,
unless I misunderstand the explanation. If we need a vote, may be a good
idea to separate this one either.
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #106039 — Christoph M. Becker — 2019-06-22T21:16:02+00:00

URL: https://externals.io/message/106012#106039

> > […]
>
> It may be supported by other extensions (btw did anybody verify that it
> actually is and gives the same results?), but this is not the reason per
> se to remove old working functions. There's a lot of duplication in
> programming languages - all (Turing-complete) languages ultimately do
> the same thing, and most practical languages have way more syntax and
> utility functions than strictly necessary to achieve desired outcome.
> This is because redundancy in expressiveness improves productivity.
> Here we have the reverse - we are forcing people who have working code
> to go back and rewrite it to essentially achieve the same result we
> already have - negative productivity. I don't see a point in doing this.

An alternative of rewriting such code would be to have the function
defined somewhere else; this could be in userland code (and maybe
somebody will make a composer package available), and this could also be
in a custom extension (and perhaps somebody publishes a respective
extension on PECL).

Thanks,
Christoph

---

## #106040 — Andrey Andreev — 2019-06-22T21:33:27+00:00

URL: https://externals.io/message/106012#106040

Hi,


>
> 
> > […]
>
>
> Thanks for bringing this up: It's a great example of why this needs to be deprecated. `array_key_exists()` actually has no support for ArrayAccess objects at all -- it only operates on (mangled) object properties. But just seeing the name and the fact that it doesn't error when passed an ArrayAccess object, it's quite easy to jump to the wrong conclusion. I've updated the RFC to mention this now.
>

Well, then I guess actually implementing ArrayAccess support should be
brought up now, but other than that the updated RFC content makes much
more sense now. Thank you.

> I don't understand what you mean by "object properties that contain arrays" though, or rather how that related to `array_key_exists()`.
>

I had a minor brain fart while originally thinking about this and it's
actually nothing. Sorry about that.

Cheers,
Andrey.

---

## #106158 — Nikita Popov — 2019-07-05T14:37:09+00:00

URL: https://externals.io/message/106012#106158

On Sat, Jun 22, 2019 at 10:21 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> enable_dl - I am not clear what is proposed - to remove `dl()`
> functionality in PHP 8 completely, even in CLI? Or to keep it in CLI
> always on and remove the directive?
> My opinion: drop the directive, let the SAPI decide if `dl()` is possible,
> with CLI keeping it. Not sure about embed though. But I guess if
> somebody needs it in embed, they probably could patch it so it enables
> the `dl()`. Not sure how easy it would be to make this per-SAPI decision
> though...
>

This is indeed the plan and I've clarified the RFC to say so. While doing
this I double-checked the implementation and found that currently `dl()` is
available not only in CLI and Embed, but also in CGI.

I think in light of this, dropping enable_dl may make less sense, as the
premise here was more of less that `dl()` is not available in server SAPIs
anyway. Or maybe the argument has to be shifted towards "use
disable_functions=dl instead, like with all other functions".

Kalle, what do you think?


> The 'real' type - see no reason to touch it, it doesn't hurt anybody.
>
> hebrev, hebrevc, apache_request_headers, is_writeable,
> convert_cyr_string, money_format, restore_include_path - leave them in
> peace (argued why in another thread). Maybe legacy extension as Zeev
> suggested, I'm fine with that.
>

money_format should really go away due to platform support reasons. Windows
has no implementation and the macos implementation appears to be buggy
(memory corruption). It nearly seems like PHP is the only major remaining
user of this function.

Magic quotes and all related - burn with fire. Magic quotes was a
> mistake, and here my BC inner voice is not able to say anything in its
> favor.
>
> array_key_exists(object) - fine with dropping object behavior. It does
> say "array".
> And btw, can we actually make it work with ArrayAccess properly?
>

Not really. Despite the name ArrayAccess::offsetExists() really has isset()
semantics, so there isn't anything that exposes pure existence (without
null check) in the interface.


> INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them.
> No point in keeping stuff that doesn't work.
>
> register_argc_argv - support making $argc/$argv always available in CLI
> but not sure about the definition of CLI. Does CGI qualify? Does embed?
> This worries me a bit. Same situation as in `dl()` - it's like we need
> some ini setting that is only accessible to SAPIs... Maybe we should
> introduce new INI level that is only settable by SAPI but not changeable
> later? Just brainstorming here.
>

Good question. Reading the code, I think the current behavior is that
anything that specifies SG(request_info).argc gets proper $argv/$argc
(these will be preserved and always available), while anything else gets
fake $argv/$argc based on GET parameters (which will be removed and never
available).

A quick grep shows these SAPIs as setting SG(request_info).argc: CLI, CGI,
Embed, Litespeed, phpdbg. So it's not even really a matter of CLI vs server
SAPIs, just whether command line args are provided by the SAPI or not.

I feel like overall this change is not really a great fit for this
deprecation RFC, and we should probably just land these changes in PHP 8.


> Reflection export() - check if any real code is using it. Reflection
> printing is kinda-sorta is the area that BC breaks may be acceptable,
> since it's unlikely production code paths would depend on it, but we
> need to check it. Undecided so far.
>
> mb_strrpos - if we promised to deprecate, we may as well do it.
>
> `implode()` - leave it alone, yes I know it's weird order, but messing
> with it helps nobody. Yes, I know, "inconsistent". Making it
> "consistent" will improve the life of exactly 0 people. Please let it be.
>

I have a related question on this one: Apparently (TIL) `implode()` also
accepts just an array, in which case glue="". Kalle, will this form also be
deprecated, or does it remain?

ezmlm_hash - undecided... it's really the niche of the niche. It also
> doesn't hurt anyone, but not sure if anybody actually using it anymore.
>
> allow_url_include - as I said, needs separate RFC. I am leaning towards
> removing it, but maybe there's some use case for it...
>
> Unbinding $this - already wrote about it, doesn't look like we have a
> choice there given that what it is trying to do seems not to be
> supported in PHP 8. So there may not be a point in even voting on it,
> unless I misunderstand the explanation. If we need a vote, may be a good
> idea to separate this one either.
>

To be clear: We can (and currently do) support this in PHP 8. It's just a
question of performance. Thanks to the removal of calling static methods
non-statically, we can now remove the `NULL` check that occurs on every
single property acces, method call, etc. If we do, it will currently come
at the cost of a separate opcode for each $this access in a closure. If we
remove the ability to unbind $this, we could do this without imposing a
cost in any common scenario (the only one would be when using $this outside
a class, e.g. in templates, which is not important).

Nikita

---

## #106163 — Nikita Popov — 2019-07-08T10:27:49+00:00

URL: https://externals.io/message/106012#106163

> On Sat, Jun 22, 2019 at 10:21 PM Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
> > […]
>
> This is indeed the plan and I've clarified the RFC to say so. While doing
> this I double-checked the implementation and found that currently `dl()` is
> available not only in CLI and Embed, but also in CGI.
>
> I think in light of this, dropping enable_dl may make less sense, as the
> premise here was more of less that `dl()` is not available in server SAPIs
> anyway. Or maybe the argument has to be shifted towards "use
> disable_functions=dl instead, like with all other functions".
>
> Kalle, what do you think?
>
>
> > […]
>
> money_format should really go away due to platform support reasons.
> Windows has no implementation and the macos implementation appears to be
> buggy (memory corruption). It nearly seems like PHP is the only major
> remaining user of this function.
>
> Magic quotes and all related - burn with fire. Magic quotes was a
> > […]
>
> Not really. Despite the name ArrayAccess::offsetExists() really has
> isset() semantics, so there isn't anything that exposes pure existence
> (without null check) in the interface.
>
>
> > […]
>
> Good question. Reading the code, I think the current behavior is that
> anything that specifies SG(request_info).argc gets proper $argv/$argc
> (these will be preserved and always available), while anything else gets
> fake $argv/$argc based on GET parameters (which will be removed and never
> available).
>
> A quick grep shows these SAPIs as setting SG(request_info).argc: CLI, CGI,
> Embed, Litespeed, phpdbg. So it's not even really a matter of CLI vs server
> SAPIs, just whether command line args are provided by the SAPI or not.
>
> I feel like overall this change is not really a great fit for this
> deprecation RFC, and we should probably just land these changes in PHP 8.
>
>
> > […]
>
> I have a related question on this one: Apparently (TIL) `implode()` also
> accepts just an array, in which case glue="". Kalle, will this form also be
> deprecated, or does it remain?
>
> ezmlm_hash - undecided... it's really the niche of the niche. It also
> > […]
>
> To be clear: We can (and currently do) support this in PHP 8. It's just a
> question of performance. Thanks to the removal of calling static methods
> non-statically, we can now remove the `NULL` check that occurs on every
> single property acces, method call, etc. If we do, it will currently come
> at the cost of a separate opcode for each $this access in a closure. If we
> remove the ability to unbind $this, we could do this without imposing a
> cost in any common scenario (the only one would be when using $this outside
> a class, e.g. in templates, which is not important).
>
> Nikita
>

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

---

Next page: https://externals.io/message/106012.md?page=2