[RFC][VOTE] Improve array to string conversion

Le mer. 25 févr. 2015 à 12:16, Xinchen Hui laruence@php.net a écrit :

Hey:

On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre francois@php.net
wrote:

Hi,

Starting the vote for https://wiki.php.net/rfc/array-to-string.

Please note that, while the initial RFC proposed both options of either
fully supporting the feature, or disabling it, the voting choices are
now :

• either definitely disabling array to string conversion,
• or keep current behavior as-is.

Vote ends March 6, 00:00 (UTC).
replace E_NOTICE with E_RECOVERABLE_ERROR??

it's a huge BC break.....

I vote -1 on this.

thanks

Regards

François

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

--

Hello,

I'm explaining here the reasons of my "-1" vote.

1. You suggest (in your PR) changing the conversion in _convert_to_string()
   but not in zend_make_printable_zval(). That makes it completely
   inconsistent.

2. It breaks code "that works":

   if (!is_string($myArgument)) {
   $logger->log("Invalid argument passed: " $myArgument)
   }

Yes, var_export() could have been used, but it breaks something that
"worked" before and this is therefore an important BC break.

3. I am wondering what it really brings to devs by changing E_NOTICE to
   E_RECOVERABLE_ERROR.

Those that want to know when this is happening can already with E_NOTICE in
their error_reporting.
Those that do not actually care might probably not care more.
I'm worried that those will fix issues like this:

$diff = array_diff($multiDimensionalArray1, $multiDimensionalArray2);

with:

$diff = @array_diff($multiDimensionalArray1, $multiDimensionalArray2);

I'm not fundamentally against the idea to break the execution when this is
happening, but I'd rather opt in for it, especially if:

$weird = (string) $anArray;

would generate an error because of a conversion with loss, while:

$oops = (float) "one hundred";

would simply not break and do not provide even a notice!

I'd rather introduce an E_CONVERSION_LOSS which would be triggered in all
case of conversion loss than just targeting the specific "array -> string"
case.

Thanks,
Patrick