This is an old revision of the document!
PHP RFC: Non-Nullable Property Checks
- Version: 0
- Date: 2019-01-23
- Author: Rowan Collins [IMSoP], rowan.collins@gmail.com
- Status: Draft
- First Published at: http://wiki.php.net/rfc/non_nullable_property_checks
Introduction
The Typed Properties 2.0 RFC adds support for typed properties to the language, including non-nullable properties. However, failing to assign a value to a non-nullable property is not an error; instead, the property remains unset, and raises an error only when it is accessed. This RFC proposes additional checks to raise the error closer to the cause of the problem in certain situations.
As pointed out by Larry Garfield, there are two ways of considering type annotations on properties: one is to assert that a value is a given type, the other is to assert that a value can only be set to a given type. The implementation currently accepted for PHP 7.4 guarantees only the first.
With a property which is declared as a nullable type, or assigned a static default value, the distinction rarely matters: in normal use, the property starts life with a valid value, and can only be set to a valid value; therefore, it will always have a valid value. However, if null is not a valid value, and there is no static default, it is trivial to leave the property in an invalid state, simply by forgetting to assign any value in the constructor.
Proposal
Backward Incompatible Changes
If this change is added before the release of PHP 7.4.0, no existing code will be affected, as previous versions do not support typed properties.
If it is for some reason delayed, there is the possibility that code which runs under PHP 7.4 will start raising errors, but such code will almost certainly have been incorrect or buggy anyway.
Proposed PHP Version(s)
PHP 7.4
RFC Impact
To Existing Extensions
Will existing extensions be affected?
To Opcache
It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.
Please explain how you have verified your RFC's compatibility with opcache.
Open Issues
Make sure there are no open issues when the vote starts!
Unaffected PHP Functionality
List existing areas/features of PHP that will not be changed by the RFC.
This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
Future Scope
This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
Proposed Voting Choices
Include these so readers know where you are heading and can discuss the proposed voting options.
State whether this project requires a 2/3 or 50%+1 majority (see voting)
Implementation
TODO
References
Rejected Features
Keep this updated with features that were discussed on the mail lists.