This is an old revision of the document!
PHP RFC: E_NOTICE for invalid container array-access
- Version: 0.1
- Date: 2016-07-31
- Author: David Walker (dave@mudsite.com)
- Status: Under Discusson
- First Published at: http://wiki.php.net/rfc/notice-for-non-valid-array-container
Introduction
PHP current array-access system works very well when attempting to access containers of type array, reference(to an array), and objects that implement ArrayAccess. However, accessing elements not of those types results in a NULL value returned without any alert as to why it's null. This feature has been requested in 37676 and duplicated in at least 39915 and 72636. PHP correctly returns a notice when you attempt to use an offset that is of an invalid type, PHP should also provide a notice when a container is of an invalid type.
Proposal
This RFC proposed to combine a couple of existing PR's[1][2] as well as my implementation to raise a E_NOTICE when a container type is used that does not contain array-accessable data. The default behavior, of a silent NULL return, is not correctly defined in the Array Documentation however is noted in a comment
As compared to the previous PR's (referenced below) this proposed implementation takes effort to limit throwing errors multiple times.
<?php $var = false; $var[1][2][3][4][5]; // This will throw a single E_NOTICE, as accessing ($a[1])[2] // is attempting to access a IS_VAR chain that is NULL. // Output would be: // Notice: Variable of type boolean does not accept array offsets $var = array(123); $var[0][1]; // This will throw an E_NOTICE, as accessing $a[0] is valid // [1] is accessing an integer as an array. // Output would be: // Notice: Variable of type integer does not accept array offsets $var = null; list($a, $b) = $var; // This will throw one E_NOTICE. Special handling to check // opcode is a list-assignment. At which point only if the dim // is 0 (ie first assignment) we will raise the notice. // Output would be: // Notice: Variable of type null does not accept array offsets
Backward Incompatible Changes
In terms of error-reporting for default INI settings there would be no BC-break for production, but there would be notices for development. Many production deployments alter default INI settings for error-reporting and as such could be exposed to this notice displaying. This would need to be documented in release notes for users to properly address in development environments.
However, error-reporting isn't the only aspect that needs to be addressed here. set_error_handler()
, if listening to E_NOTICE will be triggered for this notice regardless of INI settings. As well error_get_last()
would also contain this notice if it was the most recent error. These two operate regardless of error_reporting(0)
.
This RFC aims to limit the quantity of notices on a single line, however, large projects may have many locations that might need variable type checking around unknown container access. Typically, one might assume access of a variable to be an array or object, and could do checks to make sure the variable about to be accessed is an array, or an object.
Proposed PHP Version(s)
Next PHP 7.x (currently 7.2)
RFC Impact
To SAPIs
No expected impact to SAPI's
To Existing Extensions
No Extensions
To Opcache
No Opcodes are touched with this RFC
Open Issues
Previous discussion in this thread [3]
NULL Identity
Should NULL variables be treated as a special identity so that accessing array on a null just returns null.
- Pro: easier checking by doing a
if (!is_scalar($var))
, before doing access since NULL is not a scalar. - Con: I'd like to know if I'm accessing a null wrong.
Proposed Voting Choices
No syntax is changed, a vote of 50%+1 will be necessary
Patches and Tests
References
Current Open PR's
Previous Discussion
[3]Email Thread