Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99512
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJd4=YY2g0M19LAOeKjHrxdeAnEozjLAn2EJA6JqUVDTfpmE7Q@mail.gmail.com>
References: <CAJd4=YY2g0M19LAOeKjHrxdeAnEozjLAn2EJA6JqUVDTfpmE7Q@mail.gmail.com>
Date: Tue, 13 Jun 2017 21:15:33 +0200
Message-ID: <CAF+90c9zog4fhBPS8HCz0fd7rnvxNnsYzcjwaStSTT7=E69CXQ@mail.gmail.com>
To: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114608228004b40551dc4248"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Restarted vote on the negative arrays
From: nikita.ppv@gmail.com (Nikita Popov)

--001a114608228004b40551dc4248
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 13, 2017 at 8:44 PM, Pedro Magalh=C3=A3es <mail@pmmaga.net> wro=
te:

> Hi internals,
>
> Based on the feedback on the original RFC targeting 7.2, I have now updat=
ed
> the RFC to target version 8.0. Additionally, I changed the existing PR to
> throw a E_DEPRECATED notice on the cases where this RFC will cause a BC
> break when the change is implemented to ease the detection of such cases.
>
> I have closed the current vote (YES 14 - 16 NO) and opened a new one for
> the revised RFC targeting the next major version.
>
> You can vote (again) at https://wiki.php.net/rfc/negative_array_index
> until 28/6/2017 19:00 UTC.
>
> Regards,
> Pedro
>

As this is a significant change to the RFC, I'd recommend moving it back to
discussion first.

Without some further evaluation, I am not sure whether throwing a
deprecation from a low level hash API function like this is safe. The
deprecation may be converted into an exception and it's not immediately
clear that calling code will handle this correctly. In any case, even
assuming this is safe, what is the expected behavior if the deprecation
notice is converted into an exception? As the implementation stands right
now, the element will still be inserted into the array. Is this intentional=
?
("We don't care" is also a valid answer -- it's an edge case.)

It would also be nice to quickly check what the performance impact of this
change is (a micro-benchmark on array appends should be enough). The patch
adds a number of additional checks in a very hot code-path, which may or
may not have a measurable impact.

Regards,
Nikita

--001a114608228004b40551dc4248--