Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Giovanni Giacobbi <giovanni.g@gmail.com>,
 PHP Internals List <internals@lists.php.net>
References: <CAML1Pf4vHMfGwYEepDiT-n035=A-MR34cZTFf+Jz3oU3Cr3LqA@mail.gmail.com>
Message-ID: <f44ca736-ec6e-0c5a-2ef1-ecbc5792662a@gmx.de>
Date: Wed, 25 Jan 2017 15:05:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CAML1Pf4vHMfGwYEepDiT-n035=A-MR34cZTFf+Jz3oU3Cr3LqA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: String to array odd behaviour in 7.1
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 25.01.2017 at 14:21, Giovanni Giacobbi wrote:

> Greetings,
> 
> There is something weird with 7.1 and implicit strings to array
> conversions, so I wanted to double check with you that the behaviour is
> wanted (and perhaps the migration71 doc should be updated to reflect this.
> 
> So in the migration docs [1] you say that: " Applying the empty index
> operator to a string (e.g. $str[] = $x) throws a fatal error instead of
> converting silently to array. "
> 
> I'm going to show four cases on different PHP versions:
> 
> CASE 1: php -r '$a = "foo"; $a[] = "bar"; var_dump($a);'
> PHP 5.6.x -> Fatal Error
> PHP 7.0.x -> Fatal Error
> PHP 7.1.x -> Fatal Error
> 
> CASE 2: php -r '$a = "foo"; $a["x"] = "baz"; var_dump($a);'
> PHP 5.6.x -> string "boo" (with illegal offset warning)
> PHP 7.0.x -> string "boo" (with illegal offset warning)
> PHP 7.1.x -> string "boo" (with illegal offset warning)
> 
> CASE 3: php -r '$a = ""; $a["x"] = "bar"; var_dump($a);'
> PHP 5.6.x -> array("x" => "bar") with NO warnings
> PHP 7.0.x -> array("x" => "bar") with NO warnings
> PHP 7.1.x -> string "b" with illegal offset warning
> 
> CASE 4: php -r '$a = ""; $a[] = "bar"; var_dump($a);'
> PHP 5.6.x -> array("bar") with NO warnings
> PHP 7.0.x -> array("bar") with NO warnings
> PHP 7.1.x -> Fatal Error
> 
> I think what is bugging me here is that the docs talk about CASE 1 whose
> behaviour actually did not change, so it should mention "empty string"
> because that's where the actual change happened (CASE 4), also I think that
> CASE 3 should be rethinked.
> 
> In general I would like to raise a concern on the fact that I think the
> previous behaviour was better, after all PHP is dynamically typed so why
> not allow a variable to silently change its value silently? We know that
> using offset with strings is always illegal (CASE 2) so why not *always*
> converting it to an array and discard its previous value?
> 
> [1]
> http://php.net/manual/en/migration71.incompatible.php#migration71.incompatible.empty-string-index-operator

See <https://bugs.php.net/bug.php?id=73925>.

-- 
Christoph M. Becker