[RFC] Deprecations for PHP 7.2

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'm generally in favor of such clean up.

The only exception would be features which have only been available as
of PHP 7, currently only assertion expressions. Deprecating assertion
strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2
compatible code, even though 7.2 GA is supposed to be released in
December 2017, whereas there'll be security support for 5.6 until end of
2018[1].

[1] http://php.net/supported-versions.php

--
Christoph M. Becker

Hi Nikita

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

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.

Awesome list, thanks for your work. I got a couple of things to maybe
consider adding:

arg_separator.output/input -- Do we really need an ini to define
these, can't they be baked in or something? (I did not look at the
code)
auto_prepend/auto_append_file directives, I would be amazed if there
couldn't be some optimization complications with those too
register_argv_argc -- deprecate for non CLI?

Might have other things to add later on, these are just what I had in
mind so far

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100):

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 must have missed the discussion about each(). And this really
surprised me:

The each() function is inferior to foreach in pretty much every
imaginable way, including being more than 10 times slower.

But it is mentioned in a 9-year old comment in the manual:
https://php.net/manual/en/function.each.php#75692

A quick grep in my Drupal7 source code showed that not everybody is
aware of that. For instance, even the views module use a list() = each()
construction:
http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740
This means that at least 800,000 sites use list() = each() at the
moment.

I am fine with deprecation, but this may be more wide spread than one
might assume.

Jan

"Nikita Popov" wrote in message
news:CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...

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 am against the removal of the $errorcontext argument of error handler as
this has been a valuable part of my error handler for over ten years.
Whenever trigger_error() is called with a fatal error I write all available
details to a log file as well as sending an email. In order to obtain
additional data I use errorcontext to determine the following:

a) Was it called from a function or an object? For this I use code such as
the following:

if (isset($errcontext['this']) AND is_object($errcontext['this'])) {

b) If it was called from an object, was it one of my database objects? If
yes, then obtain some extra information using code such as the following:

    // retrieve error details from DML object
    if (method_exists($errcontext['this'], 'getQuery')) {
        $query  = $errcontext['this']->getQuery();
    } // if
    if (method_exists($errcontext['this'], 'getErrorNo')) {
        $errno  = $errcontext['this']->getErrorNo();
    } // if
    if (method_exists($errcontext['this'], 'getErrorString')) {
        $errstr = $errcontext['this']->getErrorString();
    } // if
    if (method_exists($errcontext['this'], 'getErrorString2')) {
        $errstr2 = $errcontext['this']->getErrorString2();
    } // if

Saying that I should stop using $errorcontext and instead use a debugger is
very short sighted. I NEED to have this data available in the error log as
soon as the error happens. In several cases I cannot use a debugger as my
application is running behind a client's firewall and their security
restrictions forbid the use of a debugger from outside of that firewall.

I notice that the reason for this recommendation is "because the $errcontext
can be used to modify all references and objects in the current scope." If
this is the case then why not make $errorcontext read-only so that nothing
can be changed. I can imagine lots of people reading from $errorcontext, but
how many actually write? I certainly don't.

--
Tony Marston

> 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
>

Hi Nikita,

I'm interested to see `create_function()` on this list, as one of my first
contributions to the list was suggesting its deprecation, and I didn't
feel there was sufficient consensus to go forward. Thread here:
http://marc.info/?t=138178649200002&r=2&w=2
http://marc.info/?t=138178649200002&r=1&w=2 It's possible the
intervening three years have changed things sufficiently to reconsider,
though.

On a broader note, I would like to restate my desire for some kind of
road map or plan of roughly when 8.0 is expected, to inform decisions on
things like this. Does "deprecate in 7.2" mean removal in 2 years time,
or 5, or 10?

Previously I've been answered with "the Big Feature of 8.0 will be JIT",
but I am not a fan of tying the deprecation and feature policy to
"whenever we happen to have a rewrite of the engine ready"; it muddles
product branding with API versioning. If JIT isn't ready for 10 years,
does that mean we have to wait 10 years to break BC? And if it's ready
in 2018, does that mean everything deprecated in 7.2 has to be
immediately dropped after just one year? Should we decouple the Zend
Engine version from the language version, and use separate semantic
versions for each?

Regards,

--
Rowan Collins
[IMSoP]

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 wouldn't deprecate things that 1. have no replacement, 2. are very
much in use, or 3. are harmless.

__autoload is one of group (2). I think this is used a lot, and would
not want to deprecate this until PHP 8.

I also do not see why (binary) should be removed, as it fits in category

In general, I think you should have a good reason why to remove them,
and just "it's not what we suggest you use" is not good enough. It
should be a general bad thing, before it should be considered for
removal.

Right now, the only thing I can think of is removing
mbstring.func_overload.

For ini settings, you should not throw a deprecation warning if the
setting is set to off. This covers mbstring.func_overload , but it
seems you have changed that since I read this RFC for the first time.

cheers,
Derick

Hi

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

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

I was actually gonna make an RFC for this, but the (real) cast and
is_real() function, our third alias for float/double/real could be
added to the deprecation list. It doesn't make much sense to keep
three aliases where one of them is rarely used in "real" life
applications.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

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

Hi Nikita, hi all,

https://wiki.php.net/rfc/deprecations_php_7_2

I just realized that in Symfony, we use the $errcontext argument of error
handlers to work around the limitation of __toString not being able to
throw.

Excerpt from
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L439
:

                    // Here, we know `trigger_error()` has been called

from __toString().
// HHVM is fine with throwing from __toString() but
PHP triggers a fatal error instead.
// A small convention allows working around the
limitation:
// given a caught $e exception in __toString(),
quitting the method with
// return trigger_error($e, E_USER_ERROR); allows
this error handler
// to make $e get through the __toString() barrier.

This is a hack, but that's what the Debug component is about: leverage
several hacks and ship them as a set of useful experience-enhancers to devs.

In short, I'm all for deprecating $errcontext, and looking at the ongoing
vote it'll be accepted soon.

BUT, it would great to fix the inability of __toString to throw in 7.2 also.

Regards,
Nicolas