Modify array to string conversion

• Version: 1.0
• Creation date: 2015-01-10
• Last modification date : 2015-01-11
• Author: François Laupretre, francois@tekwire.net
• Status: Under discussion
• First Published at: http://wiki.php.net/rfc/array-to-string

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

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

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

I consider this as a half-backed solution : we raise an error, which is not a 'real' error (an E_WARNING would be) and we return a useless string (anybody relying on the 'Array' value, please call me :). Off topic: I am personally against the existence of E_NOTICE and E_STRICT, which are, IMO, half-backed solutions too.

The only possible justification I imagine for the current behavior is to have stopped a flame war or for (wrong) BC reasons.

Now, the future release of a new major version may be the occasion to get rid of this. I know this is it a hot subject but I hope we can all give our opinion without starting another war.

I imagine two possible alternative and opposite behaviors :

Here, we consider that array-to-string conversion was never actively supported nor encouraged and that we have been pulling this problematic behavior behind us for years. So, it may be time to disable it definitely.

So, array-to-string conversion would be considered like object-to-string with no 'toString' method: conversion attempt generates a 'fatal catchable error'. Then, if the program was still alive, the conversion would return 'Array' as before.

It is a radical message to the developers that we don't support this feature anymore, and that fixing code is a pre-requisite to a PHP7 switch.

We could go through a migration phase with an E_DEPRECATED but the 5.7 was rejected and we already raise an E_NOTICE. So, this phase may probably be skipped.

I am not favorable to this alternative as, although it is more clear than the current behavior, I think that the second one below is a better choice.

Here, we decide that array-to-string conversion is a valid concept. We define a standard algorithm to perform the conversion, fix it in stone and encourage C and PHP code to use it with no restriction.

Of course, the first step is to remove the E_NOTICE.

The 2nd step is the choice of the conversion algorithm. What I suggest is the most intuitive choice I would expect in this case : a recursive concatenation of every non-array elements of the array tree, each of them converted to a string (a recursive implode() with no 'glue'). Array elements would be taken in array order, keys would be ignored.

Existing rules for non-array types to string conversions would be applied to all non-array members of the input array. For instance, if the array contains an object, it would be silently converted to string if the class defines a 'toString' method, and would raise a fatal catchable method otherwise.

I prefer this alternative as it adds a standard, meaningful way to convert an array to a string. There will be discussions on the algorithm to choose and I hope we won't paint the bike shed again, but the most important is to define a standard conversion mechanism and ensure it never changes.

If we deprecate array-to-string, the potential BC break is huge as a lot of existing PHP code requires turning off E_NOTICE, and the 'Array' value, while useless, can go unnoticed for a lot of reasons.

If we add full support, the removal of E_NOTICE has a negligible impact. And, as all of us probably agree that anybody relying on the 'Array' string should choose another profession, the overall BC break remains minimal.

PHP 7

Trivial. Touches every explicit or implicit array-to-string conversions.

None (yet)

No other zval type conversion should be impacted.

None

Required majority : 2/3, and even probably more :)

Very easy to implement.

Patches and tests will be written as soon as we seem to agree on something.

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

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