On Fri, Nov 18, 2016 at 3:55 PM, Nikita Popov <nikita....@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
