# RFC: Improve array to string conversion - Status: Withdrawn - Authors: François Laupretre, francois@tekwire.net - Version: 2.1 - Original: https://wiki.php.net/rfc/array-to-string - Page: https://externals.io/rfc/array-to-string - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt ## Votes ### array-to-string (closed) Yes: 34 · No: 10 Voters: aharvey (Yes), ben (Yes), brandon (Yes), bwoebi (Yes), danack (Yes), datibbaw (No), diegopires (Yes), duodraco (Yes), francois (Yes), frozenfire (Yes), guilhermeblanco (Yes), gwynne (Yes), hywan (Yes), ircmaxell (Yes), jedibc (Yes), jpauli (No), jwage (Yes), kalle (Yes), kinncj (Yes), krakjoe (Yes), laruence (No), lcobucci (Yes), leigh (Yes), lstrojny (Yes), mbeccati (No), mfischer (Yes), mike (No), mrook (Yes), nikic (No), olemarkus (Yes), patrickallaert (No), pauloelr (Yes), pollita (Yes), rasmus (No), rdohms (Yes), santiagolizardo (Yes), sobak (No), stas (Yes), till (Yes), treffynnon (Yes), tyrael (No), yohgaki (Yes), yunosh (Yes), zeev (Yes) ## Discussions on the mailing list - [\[RFC\] Improve array to string conversion](https://externals.io/message/80366.md) — started on 2015-01-11, 5 messages - [\[RFC\]\[VOTE\] Improve array to string conversion](https://externals.io/message/83581.md) — started on 2015-02-23, 4 messages - [\[RFC\]\[VOTE\] Improve array to string conversion](https://externals.io/message/84165.md) — started on 2015-03-02, 2 messages - [Question/comment about the Array to String conversion RFC](https://externals.io/message/84168.md) — started on 2015-03-02, 22 messages - [Allow throwing from __toString()](https://externals.io/message/104535.md) — started on 2019-03-01, 6 messages --- 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 : 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)