Counterargument to Deprecate Short Tags RFC V2

• Date: 2019-08-06
• Author: Zeev Suraski, zeev@php.net

An proposal has been made to deprecate PHP's short tags syntax. The proposal was first made available in V1 here, and a newer version was later made available in V2 here. The goal of this page is to provide a counterargument for this proposal, or in other words, to explain why we should not be deprecating this syntax.

The motivation for removing short tags as it is illustrated in the V2 RFC is quite weak. Essentially - it does not present any new motivations that did not exist 20+ years ago, when this syntax was first introduced. At the time, all the different potential opening and closing tags were heavily discussed, and all the implications - including the ones brought up by the deprecation RFC - were already known. There is no new 'evidence' available here.

It's certainly possible to argue that the wrong decision was made back then - but it's very difficult to justify a position claiming that the situation is so bad that we must now remove this syntax - even though nothing about the underlying dry facts has changed.

The one thing that did change, which makes it even more difficult to justify this deprecation, is that unlike back then, when PHP was rounding error in terms of language popularity, today - it is one of the most widely used languages in the world. This means that even if only a small subset of PHP developers are using this syntax - this deprecation is going to affect hundreds of thousands of people (20 years ago, it would affect virtually no one).

Short tags are controlled by an INI setting, and are consequently not portable. In addition, code using short-tags that's deployed on a server that has short tags disabled, will leak source code.

Short tags were, from the get-go, never meant for being used in portable code to begin with. After over 20 years in the wild, this is very much a known quantity that surprises hardly anyone. From the very beginning, when the discussion about what the tags would look like in PHP 3, it was clear it will be possible to disable the processing of short tags (more on that below), and that they would consequently not be usable in portable code.

Virtually all (if not literally all) PHP-based projects that are meant for redistribution - be they apps or frameworks - have rules that prohibit the use of short tags. Short tags are used, de-facto, exclusively for non-portable code by people and companies that have complete control over their stack.

In reality, deprecating short tags does not have any meaningful contribution to making PHP codebases more portable - the ones who need to be portable are already not using this syntax, and the ones which are not - aren't meant for distribution to begin with.

Short tags are not compatible with XML. XML uses <?xml ... ?> syntax, and therefore does not play nicely with servers that have short_tags enabled.

This is precisely as true today as it was back in 1997-1998 when the tags for PHP were initially discussed.

With one big difference - back in the late 90's, XML appeared to be the future of anything and everything - from configuration files, through transport protocols and all the way to databases. Fast forward 20+ years later - XML is not nearly as important today as people thought it would be, or even as it was. XML is rarely the first choice for almost all use cases - other formats - JSON, YAML, etc., which are not incompatible with short tags - are preferable in almost all cases.

To place more weight on XML incompatibility today than we did 20+ years ago (or any weight at all, for that matter) - seems awfully anachronistic.

In V1 of the RFC, an assertion was made that deprecating short tags will somehow help simplify PHP's parser. This was factually incorrect - short tags do not affect the parser of PHP at all, and have no impact on neither performance nor the complexity of the PHP codebase one way or another.

There are two main reasons for keeping short tags.

By now, it should be clear that nothing happened since the late 90's that should make us radically change our minds regarding the negative impact of having short tags in the language. If anything, it's a lot less of an issue today than it was 10 or 20 years ago (given the declining popularity of XML).

“If ain't broke - don't fix it”.

For users of short tags, deprecating them gives them a 100.0% needless headache. As illustrated above - these are not people who care about portability, or they would have figured out by now that they shouldn't be using that syntax. It's not that they would suddenly start distributing their code, just because it can theoretically run on any server out there.

Put yourself in the shoes of a user or company that has been using short tags for their internal projects for the last decade, and are now forced to spend time and money in order to run be able to run your app on PHP 8 - for absolutely no gain. What do we tell them when they ask why we did it? There's simply no good answer.

PHP, like many other packages and languages - suffers from a long tail of users that are running on older versions for a variety of reasons. One of the key reasons is the complexity of upgrading. With this deprecation - we're making it more difficult for users to stay current, for no gain. As it is well within the consensus that it is our interest for users to upgrade as quickly as possible to newer versions (if only for security reasons) - breaking compatibility in such a wide scale for no gain is a bad bargain.

Most of the people who are going to vote on this RFC are not users of short tags. I'm included on that list - I never use short tags in any PHP code that I write, and as far as I recall - I never have.

It is important to stress that this is not the question. The question we should be asking ourselves isn't whether we think short tags are a good idea, or whether we will be affected by removing them. The question we should be asking ourselves is whether we think short tags is so catastrophically bad - that it's worth to put hundreds of thousands of people through additional pain when upgrading.

The internals@ mailing list tends to attract developers who are at the more at the forefront of PHP development than the PHP userbase at large - for quite obvious reasons. We should be thinking about the entire userbase, including parts of the userbase that are under-represented on internals@ - but are still very much an important part of the PHP ecosystem. I believe that the vast majority of the substantial number of folks who voted against the V1 of the deprecation RFC, did so because of that - and not because they use or like short tags - presumably none of them do.

Breaking compatibility should have an exceptionally good case, with tangible, strong gains associated with it. These gains should far outweigh the negative impact associated with the introduction of the deprecation itself.

Deprecating short tags, as illustrated in this counterargument, brings us virtually no value at all. It does, however, introduce very significant breakage for a wide range of users - for whom it will be very difficult (read: impossible) to explain why we made them go through this headache to begin with.

Our time, and even more so - the time of our users - is much better spent elsewhere.