Improve array to string conversion View as Markdown

This RFC is withdrawn because discussion shows that the subject is far from mature and potential side effects require more discussions. It will probably be revived in the future but potential BC breaks reserve such changes for a major release.

Introduction

Currently, array to string zval conversion raises an E_NOTICE and returns a string containing 'Array'.

This RFC considers this behavior as non-optimal and proposes improvements.

Proposal

As seen above, zval conversion from array to string, implicit or explicit, gives E_NOTICE and 'Array'.

We consider this as no more than a temporary half-backed solution : we raise a low-level error and we return a useless string.

Now, the release of a new major version is the occasion to make a definitve decision.

Note: the RFC originally proposed, either to fully support the feature, or to deprecate it.
Following discussion, it was decided to only propose the option of deprecating it.
So the other option was removed, and can be consulted via older versions of the RFC.

1st alternative: deprecate

Here, we consider that array-to-string conversion was never actively supported nor encouraged, that, it most cases, its only effect is hiding bugs, and that it is time to disable it definitely.

Another argument is that there never was an agreement on the 'standard' way to convert an array to a string.

So, we propose that Array-to-string conversions are considered exactly the same as object-to-string with no '__toString' method: any conversion attempt generates an E_RECOVERABLE_ERROR. Then, if the program is still alive, the conversion returns 'Array' as before. The E_NOTICE message is suppressed. No more worries about hiding bugs with this logic, as masking such an error level is a strong user decision, definitely not the same as disabling E_NOTICE.

We could go through a migration phase using E_DEPRECATED, but we consider that, since an E_NOTICE is currently generated, it may be considered as a deprecation notice, and we can directly switch to E_RECOVERABLE_ERROR.

Another argument is that, while this one should not be very problematic, it is always better to introduce a BC break in a major version.

If 5.7 is revived, it will contain an interim version, with E_NOTICE replaced by E_DEPRECATED.

2nd alternative: full support

Removed

Backward Incompatible Changes

The potential BC breaks are important because a lot of PHP code runs in E_NOTICE-disabled environments and the 'Array' return value, while probably invalid, may easily go unnoticed.

In balance of this, we can consider that raising the error level in environments where E_NOTICE messages are disabled, will generally help discovering bugs that had remained unnoticed because the error level was hidden.

Actually, during the discussion, the opinions seemed to converge towards the position that discovering undetected bugs is probably more important than potential BC breaks.

Proposed PHP Version(s)

7.0

RFC Impact

Touches every explicit or implicit array-to-string conversion, whether called from extensions or in PHP code.

Open Issues

None

Unaffected PHP Functionality

No other type conversion is impacted.

Future Scope

None

Proposed Voting Choices

Basic Yes/No : Yes to replace E_NOTICE with E_RECOVERABLE_ERROR, No for no change.

Vote: array-to-string — Yes: 34 · No: 10 (closed)

Voting will close March 6th, 00:00 (UTC).

Required majority : 2/3 of voters.

Patches and Tests

Patch provided, fixing existing tests is under way.

Implementation

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

References

PR : https://github.com/php/php-src/pull/991

32 tests are broken by this change. The coresponding fixes are under way and not included in the PR.

Rejected Features

(Keep this updated with features that were discussed on the mail lists)