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

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.

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

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.

Next PHP 7.x (currently 7.2)

No expected impact to SAPI's

No Extensions

No Opcodes are touched with this RFC

• Previous discussion in this thread [3]

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.

Should we ignore throwing warnings for list() accesses? (where $foo = null)

• list($a, $b) == $foo -- Warn for each list element? First?
• foreach(list($a, $b) = each($foo)) -- Would need to prevent warn on 'final' null each

No syntax is changed, a vote of 50%+1 will be necessary

RFC Proposed Implementation

[1] PR 866

[2] PR 1269

[3]Email Thread