Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <778F345F9918474AB8CAAB03082ECBF7@pc1>
References: <5576051A.3040800@gmx.de> <55760771.6020802@gmail.com>
 <CAGa2bXaknp0sNwk0JqfUPhURToazTfS40cy9ycY09XJT7AeaCw@mail.gmail.com> <778F345F9918474AB8CAAB03082ECBF7@pc1>
Date: Tue, 9 Jun 2015 19:44:58 +0900
Message-ID: <CAGa2bXZQb3UooF+cZJ9jKv0uVLFZSgcN=xoE6mYLG8UDZqc_Qg@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Christoph Becker <cmbecker69@gmx.de>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1139e66c7f557205181375bf
Subject: Re: [PHP-DEV] Array dereferencing of scalars
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1139e66c7f557205181375bf
Content-Type: text/plain; charset=UTF-8

Hi Matt,

On Tue, Jun 9, 2015 at 7:04 PM, Matt Wilmas <php_lists@realplain.com> wrote:

> Hi all,
>
>
> ----- Original Message -----
> From: "Yasuo Ohgaki"
> Sent: Tuesday, June 09, 2015
>
>  Hi all,
>>
>> On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev <smalyshev@gmail.com>
>> wrote:
>>
>>  > Would throwing a notice or a warning on array deferencing scalars
>>> > be acceptable for PHP 7.0, or does this need an RFC?
>>>
>>> I think this does need an RFC, and for 7.0, pretty much no new language
>>> changes are acceptable anymore, since we're past the timeframe.
>>>
>>
>>
>>  <?php
>>  $foo = 42;
>>  $foo['bar']; // => NULL
>>
>> This code cannot be right.
>> How about fix this as a simple bug?
>>
>
> I just realized this behavior a couple months ago, after being annoyed by
> "needing" to use isset() to avoid a Notice in rare cases.  (I've always
> hate, hate, hated the isset() mess just trying to assign stuff -- I wanted
> a value-returning IFset() instead!  Now we have ??, but still can't do
> var_dump($var ??).)
>
> Anyway, I realized after checking the code that this is actually
> intentional and always has been, it seems.  Really glad that I could rely
> on this and it makes things simpler and cleaner! :-)
>
> Note that I'm referring to accessing NULL as an array (that I'd like to
> rely on).  The other bool/int scalar without-a-notice case did/does seem a
> bit odd.
>
> So if there's a change, how about only changing it for non-NULL values?
> Otherwise, this:
>
> $v = NULL; $v[0][1][2][3][4][5][6][7][8][9];
>
> is supposed to give 10 Notices?!  That's dumb, and ugly, and looks like
> what the Pull Request is doing with the updated tests.  Even worse in the
> case where the variable is undefined...
>

I fully agree that current behavior could be used meaningful ways. However,

 <?php
 $foo = 42;
 $foo['bar']; // => NULL
 $v = NULL;
 $v[0][1][2][3][4][5][6][7][8][9]; // NULL

this code is semantically wrong and I would like to have error/exception
for such
erroneous codes. It's inconsistent with array object, too.

Raising exception/error is correct behavior for types that aren't array.
To avoid errors, users should use isset()/is_array()/etc.

Since we have debate for this PR, this PR would be good for RFC targeting
PHP 7.1.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1139e66c7f557205181375bf--