PHP RFC: Deprecations for PHP 7.4
- Date: 26th June, 2018
- Status: Under Discussion
The RFC proposes to deprecate the listed functionality in PHP 7.4 and remove it in PHP 8.
The following list provides a short overview of the functionality targeted for deprecation, while more detailed explanation is provided in the Proposal section:
- The 'real' type
- Magic quotes legacy
INPUT_REQUESTinput types for the filter extension
mb_strrpos()with encoding as 3rd argument
implode()parameter order mix
$thisfrom non-static closures
Each feature proposed for deprecation is voted separately. Each vote requires a 2/3 majority, independently of whether it is a language or standard library change. All votes refer to deprecation in PHP 7.4 and removal in PHP 8.0.
enable_dl php.ini directive
enable_dl php.ini directive controls whether or not the
dl() function is available. However, as of PHP 5.3, the
dl() function was limited to the CLI and Embed SAPIs and between PHP 5.3.9 and 7.0.0, it was also available in the FPM SAPI.
This means that the
enable_dl effectively has no greater meaning as it will never be available in a shared environment, and any CLI user could easily bypass it anyway.
Proposal: Add a deprecation warning if
enable_dl is non zero at start-up and when using CLI or Embed.
The 'real' type
Currently PHP has a float data type, with 2 additional aliases: double & real. The latter is very very rarely used and should be deprecated. This includes both the
(real) type-cast and the
is_real() function. Currently the
settype() function does not support the 'real' string, so it is not affected.
Upgrading is relatively easy and can be done by replacing all
(real) type-casts with
(float) and all
is_real() calls with
Proposal: Add a deprecation warning for each time the
(real) type-cast is used and each time the
is_real() function is called.
The hebrev() and hebrevc() functions
hebrevc() functions are functions that helped make websites hebrew before browsers properly supported RTL, by simply converting the nature of RTL to LTR writing for easier display on websites. All modern browsers nowadays properly support unicode and RTL text direction and therefore it seems reasonable to deprecate these functions.
hebrevc() function is essentially the same as calling
nl2br() on the result of a
Proposal: Add a deprecation warning if either
hebrevc() is called.
Magic quotes legacy
PHP's infamous magic_quotes configuration was removed in PHP 5.4 and the function implementations of checking whether or not these settings have been enabled have returned false since then. With PHP 7.0 not having magic_quotes at all, it is time to deprecate these functions and remove them entirely.
Add a deprecation warning if either
get_magic_quotes_runtime() is called.
This should only impact legacy code bases prior to PHP 5.4, running non-supported versions of PHP.
array_key_exists() with objects
The documentation already marks the use of array_key_exists() with objects as legacy behavior:
For backward compatibility reasons, array_key_exists() will also return TRUE if
keyis a property defined within an object given as
array. This behaviour should not be relied upon, and care should be taken to ensure that
arrayis an array. To check whether a property exists in an object, use
array_key_exists() on objects also has some technical issues: It operates directly on mangled property names and does not respect property visibility. Furthermore, it does not take into account differences in normalization between array and object keys, so incorrect results may be returned for properties with integral keys.
Additionally, the fact that
array_key_exists() accepts objects may mistakenly lead users to believe that it can operate on
ArrayAccess objects in a sensible manner. This is not the case:
array_key_exists() has no support for
ArrayAccess, it exclusively works on mangled object properties.
Proposal: Throw a deprecation warning if an object is passed to
Magic quotes were deprecated all the way back in PHP 5.3 and later removed in PHP 5.4. The filter extension implements a sanitization filter that mimics this behavior of
magic_quotes by calling
addslashes() on the input in question.
As of PHP 7.3, a new alias of this filter was added
FILTER_SANITIZE_ADD_SLASHES) to help ease the migration and allow us to move away from the
magic_quotes name as calling
addslashes() can still potentially be useful.
Proposed action: Emit a deprecation notice each time the
FILTER_SANITIZE_MAGIC_QUOTES filter is used and advice users to use the
INPUT_SESSION & INPUT_REQUEST input types for the filter extension
The filter extension implements a set of
INPUT_XXX constants for telling the source of where the input is coming from. However, the
INPUT_REQUEST inputs were never implemented, but their constants are, and simply emit an
E_WARNING when used.
Impact: Minimal as they do not serve any function and functionality relying on this is broken (non functional).
Proposed action: Keep the
E_WARNING and mention that these will be removed in a future version of PHP.
This function with an Apache-specific name is also available in other SAPIs, even though it is also available under the SAPI-independent name
getallheaders(). The SAPI-specific function should be removed in favor of the more general one.
Proposed action: Mark
apache_request_headers() as deprecated.
register_argc_argv ini directive
This ini setting controls whether the
$argc variables are registered. On CLI SAPIs these contain the CLI arguments, on non-CLI SAPIs they contain the
GET string parsed as if it were CLI arguments.
On CLI SAPIs
register_argc_argv=1 is a “hardcoded” ini setting, which means that it cannot be disabled through php.ini, it may only be overridden on the command line using
-d register_argc_argv=0. For other SAPIs this ini setting also defaults to on, but both
php.ini-production disable it.
This ini setting should be removed for two reasons: On CLI SAPIs it is a liability, which prevents us from strictly guaranteeing the availability of
$argv. On non-CLI SAPIs this functionality seems to be of questionable usefulness, while also negatively impacting performance and perpetuating questionable security practices.
Proposed action: Remove this option without deprecation in PHP 8. On CLI
$argv will always be available, on non-CLI it will never be available. Throwing a deprecation notice when
$argv is used on non-CLI SAPIs is technically too involved to be worthwhile.
Reflection export() methods
Reflector interface, which is implemented by all reflection classes, specifies two methods:
export(). The latter is a static method which, ostensibly, does not accept arguments. In reality this static method is implemented with varying signatures in each subclass, something which would normally result in an incompatible signature error. However, the implementation uses an internal mechanism to suppress this error.
export() methods are essentially equivalent to a combination of the class constructor and
__toString(). For example:
ReflectionFunction::export('foo'); // same as echo new ReflectionFunction('foo'), "\n"; $str = ReflectionFunction::export('foo', true); // same as $str = (string) new ReflectionFunction('foo');
As such, the
export() method is wholly unnecessary, confusing, and violates PHP's own inheritance rules.
Proposed action: In PHP 7.4 remove the method from the
Reflector interface and deprecate all implementations of the method in reflection classes. In PHP 8 also remove the implementations.
mb_strrpos() with encoding as 3rd argument
The documentation for
The encoding parameter was moved from the third position to the fourth in PHP 5.2.0. For backward compatibility, encoding can be specified as the third parameter, but doing so is deprecated and will be removed in the future.
However, this deprecation has never been realized in the implementation. The need to support both signatures makes this parameter behave subtly different from other integer parameters (e.g. it is not subject to strict types). As little software is expected to support both PHP 7.4 and PHP 5.1, enforcing the new signature does not pose a significant backwards compatibility concern.
Proposed action: In PHP 7.4 throw a deprecation warning if an encoding is passed as the 3rd argument. In PHP 8 change the argument to accept an integer.
is_writeable() function is an alias of
is_writeable() is notorious in the sense that it has a spelling mistake in its name and since the introduction of
is_writable() been considered soft deprecated.
Proposal: Deprecate the alias
implode() parameter order mix
implode() function historically supports passing the
$pieces parameters in reverse order from the documented order of arguments. However, this is inconsistent and the only function in the standard library which exhibits this behavior, and it should be amended.
This naturally also affects the
Proposal: Emit a deprecation warning if calling
convert_cyr_string() function allows conversion between cyrillic character sets. This is a legacy function back from when PHP didn't provide a lot of utility to convert between character sets. Today we have extensions like
iconv that allow this kind of conversion in a more general perspective. On top of this, this function also uses non-standard naming of character set names.
Proposal: Deprecate this function
money_format() function allows currency based on locale-specific settings to be presented using the C function
strfmon(). However some systems do not support this function, notably Windows. The functionality for formatting currency as provided by the
intl extension should be used instead
intl extension also provides even further capabilities to parse currencies using
NumberFormatter::parseCurrency() for any locale supported by ICU and not just the system which PHP is installed on.
Furthermore, the strfmon implementation seems to have an internal buffer overrun on macos, which indicates that this functionality is not well tested.
Proposal: Deprecate this function
ezmlm_hash() function creates hashes of email addresses which the EZMLM/QMail email mailing list system understands. However, this function takes any input as long as it is a string, and doesn't care whether this is an email address or not and therefore can create possible hash collisions.
Besides that, the function is of limited usage for the average PHP developer given the EZMLM/QMail system is barely maintained and its last release was in 2007. The function was most likely added since the PHP.net infrastructure uses that for the mailing lists, however it can be implemented in userland code with ease for those still supporting this.
Proposal: Deprecate this function
allow_url_include (disabled by default) ini directive allows the
include_once language constructs to use url wrappers. To use this ini directive, the
allow_url_fopen ini directive must also be enabled.
Setting this directive to on enables a potential security hazard if the path sent to either of the include constructs is crafted by external data. The ability to include a PHP file from a remote domain is questionable and has a huge potential security risk and therefore should be deprecated from PHP.
Proposal: Add a deprecation notice if
allow_url_include=1 on startup
This function is essentially an “alias” of doing
ini_restore('include_path'). The main rationale for this is to clean up the standard library for consistency, similar to what we have done with other functions that are just wrappers for ini directives.
Proposal: Deprecate the “alias”
Unbinding $this from non-static closures
Currently it is possible to unbind the
$this variable from a closure that originally had one by using
$closure->bindTo(null). Due to the removal of static calls to non-static methods in PHP 8, we now have a guarantee that
$this always exists inside non-static methods. We would like to have a similar guarantee that
$this always exists for non-static closures declared inside non-static methods. Otherwise, we will end up imposing an unnecessary performance penalty either on
$this accesses in general, or
$this accesses inside such closures.
Proposal: Deprecate unbinding
$this from a non-static closure declared inside a non-static method. A
$this binding can be avoided in the first place by marking the closure as
Backward Incompatible Changes
For PHP 7.4 additional deprecation notices will appear. For PHP 8.0 the previously deprecated functionality will no longer be available.
Each of the bullet points above will get a separate vote. All votes will require a 2/3 supermajority, independently of whether they are language changes or not.