PHP RFC: Deprecate short open tags, again
- Date: 2019-07-23
- Author: George Peter Banyard firstname.lastname@example.org, Nikita Popov email@example.com
- Status: Declined
- Target version: PHP 7.4
- Implementation: https://github.com/php/php-src/pull/4263
- Counterargument: https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
This RFC has been granted an exemption to land in PHP 7.4 after feature freeze by the release managers for PHP 7.4 Derick Rethans firstname.lastname@example.org and Peter Kokot email@example.com
In addition to
<?php, PHP allows opening PHP scripts with just
<? if the
short_open_tag ini setting is enabled. This RFC proposes to deprecate and remove this configuration-dependent syntax.
The deprecation of short open tags was previously accepted as part of deprecate_php_short_tags. However, a substantial amount of discussion was generated only after the RFC has been accepted, and some concerns were raised over the implementation approach. This RFC supersedes the previous one and proposes a different deprecation approach.
<? short open tag is controlled by the
short_open_tag ini setting. This ini setting is enabled by default (if no ini files is used), but disabled in both
short_open_tag is enabled
<? is interpreted as the start of a PHP context. If
short_open_tag is disabled,
<? is interpreted as literal text without special meaning.
<?= combined opening and echo tag is not controlled by
short_open_tag. It is always available, and will continue to be always available after this RFC.
Motivation for removal
There are two primary motivations for removing short open tags:
short_open_tag is an ini setting that control core language syntax. This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration of the deployment environment. Worse than that, code using short open tags deployed on a server using
short_open_tag=0 will leak application code, because short open tags are silently ignored.
Nowadays the PHP project has a hard policy against ini settings that affect core language behavior. Short open tags are one of the final leftovers from the time before this policy was in place.
Second, short open tags are not compatible with XML declarations
<?xml ... ?> and XML processing instructions
<?pi ... ?>. This means that the use of XML in template files is also non-portable: If deployed in an environment with
short_open_tag=1, it will cause a syntax error. (Technically a processing instruction could also coincide with valid PHP code and be executed as such, but this is unlikely.)
Deprecation and removal proposal
In PHP 7.4
short_open_tag remains enabled by default: Changing the default could result in code leaks during upgrades, if people rely on the default value rather than explicitly enabling them. Instead:
short_open_tagis enabled and
<?is used, a single deprecation notice is emitted.
short_open_tagis enabled, but
<?is never used, no deprecation notice is emitted (as before).
<?has no special meaning and is interpreted as plain text (as before).
In PHP 8.0 the deprecation notice is converted into a parse error:
short_open_tagis enabled, the use of
<?is a parse error.
<?has no special meaning (as before).
In PHP 9.0 support for short_open_tag is dropped entirely:
<?never has special meaning, it is always interpreted as plain text.
This deprecation and removal plan avoids unintentional code leaks during PHP version upgrades.
While a migration of a legacy codebase from short open tags to standard
<?php tags may seem daunting, it can be reliably automated.
For example, the
“full_opening_tag” fixer from PHP-CS Fixer can be used. Other coding style and compatibility fixers also provide this functionality.
Backward Incompatible Changes
Short open tags
<? will be removed.
<?= continues to always be available.
A counterargument for this deprecation proposal is available here. It is supported by Rasmus Lerdorf, Zeev Suraski, Dmitry Stogov, Sara Golemon.
Require a 2/3 majority as per the Voting RFC.
Voting started on 2019-08-06 at 11:30 UTC and is expected to last two (2) weeks until 2019-08-20
Version 2 (this one) RFC Vote Announcement on Internals (link to External.io)
Counter arguments to this RFC
Version 2 (this one) RFC Announcement on Internals (link to External.io)
Version 1 of RFC Vote Announcement on Internals (link to External.io)
Version 1 of RFC Announcement on Internals (link to External.io)
Initial feedback on Internals (link to External.io)