PHP RFC: "var" Deprecation

• Date: 2016-03-10
• Author: Colin O'Dell colinodell@php.net
• Status: Declined
• Discussion: http://markmail.org/message/523vpfo2q5dwqyed

This RFC proposes that var be deprecated in PHP 7.1 (in favor of public) and its functionality removed in PHP 8.0.

var would remain a reserved word in PHP 8.0 for potential future usage.

An upgrade tool is provided to automatically replace all instances of var with public. Code modified with this tool would be fully compatible with PHP 5, 7, and 8.

var is currently a simple alias for public. However, public provides more functionality than the limited subset that var supports. Because var only offers a duplicate yet limited subset of functionality, this RFC proposes the deprecation of var in favor of public.

PHP 4 introduced the var keyword as the only means to declare class properties. Later on PHP 5 added the public, protected, and private keywords for declaring these properties with a certain visibility level. To quote the documentation:

“The PHP 4 method of declaring a variable with the var keyword [was] supported for compatibility reasons (as a synonym for the public keyword)”

(emphasis added)

This alias was left intact for PHP 7.

public, protected, and private can also be used to declare static members and constants (coming in PHP 7.1) whereas var cannot.

This will eliminate duplicate functionality in the language. Both var and public behave identically for non-static member variables and therefore both are not technically needed (other than for backwards-compatibility).

The only functional difference between var and public is that the latter also supports static members and constants (coming in PHP 7.1):

<?php
class Example
{
    public $foo;        // Works
    public static $foo; // Works
    public const FOO    // Works
 
    var $foo;           // Works
    var static $foo;    // Doesn't work
    var const FOO;      // Doesn't work
}

var is therefore a limited subset of public.

PHP 8.0 is likely several years away. Deprecating this now (rather than later) would provide developers with sufficient notice that their code may need to be modified to work on 8.0.

Because var is currently an alias for public, updating older code is as simple as replacing var with public everywhere it appears. A utility script has been provided with this RFC to aid with the transition.

var is a legacy feature from PHP 4 which has been superseded by the visibility keywords. It was kept in PHP 5+ for backwards-compatibility. Removing it would help clean up the lesser-used legacy bits of the language.

There is precedent for deprecating and eventually removing other legacy features (with modern equivalents) as part of major releases:

• PHP 4 constructors were removed in 7.0
• Alternative PHP tags were removed in 7.0
• Several other previously-deprecated features were removed in 7.0

The top 10,000 packages on Packagist were analyzed (along with their dependencies) to determine the proliferation of var in the PHP ecosystem:

Because dependencies may have already been counted as “packages using var internally”, the true utilization is somewhere between 4 and 8%.

The total number of public and var keywords were counted across every file of every package (including dependencies which may be counted multiple times):

• 94% - public (1,650,084 instances)
• 6% - var (98,745 instances)

The following packages are the “worst offenders”, making up 62% of the total number of var keywords found:

• 22% - simpletest (22,116 instances)
• 17% - phpseclib (16,648 instances)
• 14% - mpdf (14,000 instances)
• 9% - simplepie (8,745 instances)

Updating these packages would drop overall var utilization to 1.5 - 3.0%.

This survey confirms that modern PHP development has largely moved away from var. Accepting this RFC will therefore have minimal impact on the ecosystem.

There are no technical issues with the current implementation of var and therefore no urgency to remove it.

PHP 4 classes will no longer function as-is in PHP 8.0. Furthermore, any classes written in PHP 5.x or 7.x may also break in 8.0 if they use var. BC breaks should not be taken lightly.

This change does not introduce any new functionality for developers. Those who are not using var will see no impact. Those who do use var will need to update their code.

Some developers do not feel comfortable replacing var with public because they did not intend for those variables to explicitly be public. Although replacing var with public does result in the same functionality, it may unintentionally imply that those variables were explicitly intended to be public (which may not be the case).

PHP 7.1 - 7.x: usages of var will raise a deprecation notice but otherwise work as-is.

PHP 8.0: Usages of var will throw a parse error.

An upgrade tool is provided which automatically replaces all instances of var with public. Code modified with this tool should be fully-compatible with PHP 5, 7, and 8.

None

?

?

Reserving the var keyword will allow it to be used for new functionality in 8.0 and beyond.

The vote is a simple Yes/No on whether to deprecate var in PHP 7.1 and remove its functionality from 8.0 (but reserve the keyword for future usage).

As this is a language change, this RFC requires a 2/3 majority to pass.

Voting started on 2016-03-24 and will end on 2016-03-31 at 12:30 UTC.

Deprecate `var` in 7.1 and remove it from 8.0?
Real name	Yes	No
aharvey
alan_k
andi
bishop
brandon
bukka
bwoebi
chregu
colinodell
daverandom
derick
dmitry
francois
frozenfire
galvao
guilhermeblanco
iliaa
jwage
klaussilveira
krakjoe
laruence
lcobucci
leigh
leszek
levim
lstrojny
marcio
mariano
mbeccati
mcmic
mike
nikic
ocramius
pajoye
patrickallaert
pauloelr
philip
philstu
pierrick
rasmus
rdohms
remi
salathe
santiagolizardo
sebastian
sobak
stas
svpernova09
tpunt
trowski
tularis
yunosh
zeev
zimt
Final result:	31	23
This poll has been closed.

• https://github.com/php/php-src/compare/master...tpunt:deprecate-var (Created by Thomas Punt)

• Official discussion thread
• Pre-draft mailing list discussion
• Reddit discussion