Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97452
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
Date: Wed, 21 Dec 2016 17:46:58 +0100
Message-ID: <CAF+90c8+PKJMzD3GM=VJDi5wCWArZhY0r7=sHv4U-wNXTpn7aA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115ee3cbc40e905442de682
Subject: Re: [RFC] Deprecations for PHP 7.2
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0115ee3cbc40e905442de682
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 18, 2016 at 3:55 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals!
>
> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
> due to time constraints. Now I'd like to propose an extended version for
> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
> performance.
>
>     https://wiki.php.net/rfc/deprecations_php_7_2
>
> The RFC combines a number of deprecation and removal proposals. Each one
> will get a separate 2/3 majority vote. The RFC overlaps with some recently
> discussed topics (each, binary strings) -- I'm fine with dropping these if
> someone has a more specific RFC.
>
> I expect some of these are no-brainers, while others are more
> controversial -- please share your specific concerns.
>
> Thanks,
> Nikita
>

I would like to proceed to voting on this RFC soon.

There are only two items on this list that I am not entirely certain about:

a) assert() with a string argument: Multiple people pointed out that it
might be too early to deprecate this function. In particular, some Drupal
contributors mentioned that Drupal currently uses assert() with string
arguments as an optimization to avoid executing certain code in production.

I have changed the RFC to clarify that assert() with a string argument will
only throw a deprecation warning if assertions are enabled. As such
projects have a choice between either using the non-string form and
incurring a penalty in production on PHP 5 (my default recommendation), or
using the string form and incurring a penalty in debug mode on PHP >=7.2
(the penalty being caused by deprecation warnings). The latter might be
preferable in some cases, especially as the string form of assert() is
already very slow if assertions are enabled.

b) The $errcontext parameter for the error handler. A few people raised
concerns about this, but on further discussion it always turned out that
they were interested in information provided by debug_backtrace(), not by
$errcontext. I have now added an explicit reference to debug_backtrace() to
the RFC.

I will likely proceed with both deprecations included and let voting decide
on the question.

Regards,
Nikita

--089e0115ee3cbc40e905442de682--