Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.40.113 as permitted sender)
To: Niklas Keller <me@kelunik.com>, "Christoph M. Becker" <cmbecker69@gmx.de>,
	David Walker <dave@mudsite.com>, PHP internals <internals@lists.php.net>
CC: Nikita Popov <nikic@php.net>
Thread-Topic: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
Thread-Index: AQHR/sbmD9xxW9A3CEyHAOpTP2AfSKBiom/BgAAa3wCAACE8lA==
Date: Wed, 31 Aug 2016 10:05:48 +0000
Message-ID: <BY2PR0201MB1784DB754435DFDDC5B0200CBFE30@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CADVQu1QXag1h_hnOcFYejMbsDrV+4ZQCwKNJmb4EedBB6S33Ww@mail.gmail.com>
 <1e6cac8a-e1af-c9e7-a900-a2efda0771dd@gmx.de>
 <BY2PR0201MB17843B394401BED590828E3ABFE30@BY2PR0201MB1784.namprd02.prod.outlook.com>,<CANUQDChTD17kqGe+621wkEzaq-WZoSZH7MTSwP-9EVLqRmhvcg@mail.gmail.com>
In-Reply-To: <CANUQDChTD17kqGe+621wkEzaq-WZoSZH7MTSwP-9EVLqRmhvcg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB1784DB754435DFDDC5B0200CBFE30BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 10:05:48.6334
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container
 read-adccess
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB1784DB754435DFDDC5B0200CBFE30BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

RFC proposes to emit warning, but the provided code throws unrelated "Unsup=
ported operand types" exception.


I see, that after few weeks of work, the implementation (just few lines of =
C code) is still hackish and incomplete.

This makes me think that, the feature can't be cleanly implemented, and I v=
ote against it.


Thanks. Dmitry.


________________________________
From: Niklas Keller <me@kelunik.com>
Sent: Wednesday, August 31, 2016 10:58:16 AM
To: Dmitry Stogov; Christoph M. Becker; David Walker; PHP internals
Cc: Nikita Popov
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-=
adccess

Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> schrieb am Mi., 31.=
 Aug. 2016, 08:37:
I vote NO, because the implementation introduces more problems than intents=
 to fix.

For example the following code starts to throw exception:


<?php $a =3D [null]; $c =3D null; var_dump($a[0][0] + $c[0]); ?>

Array access on null should always throw IMO.

BTW, I'm not against the feature, I'm against the implementation.

It's just can't be committed in current state.

I think we vote on features, not implementations. Therefore you should prob=
ably have voted yes.

Thanks. Dmitry.


________________________________
From: Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>>
Sent: Thursday, August 25, 2016 2:49:51 PM
To: David Walker; PHP internals
Subject: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adcc=
ess

On 16.08.2016 at 17:55, David Walker wrote:

> I raised this concept a couple weeks ago to a couple +1's.  Discussion wa=
s
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2].  I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
> [1] https://github.com/php/php-src/pull/2031
> [2] https://wiki.php.net/rfc/notice-for-non-valid-array-container

For the record, the RFC rightly claims:

| The default behavior, of a silent NULL return, is not correctly
| defined in the Array Documentation however is noted in a comment

I have documented this behavior now[3], and removed the note, which was
not quite correct, because it claimed that TRUE would be returned when
array dereferencing NULL, bool or int.

[3] <http://svn.php.net/viewvc?view=3Drevision&revision=3D339937>

--
Christoph M. Becker



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--_000_BY2PR0201MB1784DB754435DFDDC5B0200CBFE30BY2PR0201MB1784_--