On Tue, Jan 25, 2022 at 12:47 AM Mark Randall <marand...@php.net> wrote:
> Internals, > > PHP 9.0, likely a few years away at this point, is our next opportunity > to make significant breaking changes. > > So I thought it would be appropriate to start a thread discussing what > breaking changes we might want to include in it, specifically in > relation to error handling behaviour both at engine level, and > potentially library level. > > By discussing and passing RFCs sooner rather than later, end users and > library maintainers will have much more advanced notice than if we > waited until 8.4 had released. > > My goal is to help coordinate putting forth a set of individual RFCs, or > maybe a collective set similar to > https://wiki.php.net/rfc/engine_warnings that will specifically target > PHP 9.0, even though that version does not yet have a release date, or > even a release year. > > Nothing in this conversation will preclude others from passing > additional RFCs in the future years that also target PHP 9 error > promotion, or, for that matter, reversing those decisions potentially > made here, if necessary. > > > For my part I will be putting forward two votes which will hopefully > complete the migration process started in Nikita's engine warnings RFC: > > > ** Undefined Variables Promoted to Error ** > > PHP currently treats reading an undefined variable as though it were a > null, emitting a warning message in the process. This was previously > promoted from a notice in the PHP 8 engine warnings RFC. > > At the time a 3 way vote was held between promoting to an error > exception, a warning, or leaving it as a notice. > > At the time, 56% voted in favour of throwing an Error, 28% in favour of > a warning, and the remainder leaving it as a notice. > > My understanding is that many of those who voted to raise it to a > warning did so because they felt that jumping straight from a notice to > an Error was too much in one go. > > As it will have been a warning for around 5 years by the time PHP 9 is > released, I expect that there will now be a healthy super majority to > bump this up to throwing an error. > Something I want to add here is that there is also an important technical motivation behind promoting undefined variable notices to exceptions: The big problem with these (from a pure implementation perspective) is that we need to throw the warning and continue running. But the warning might call a custom error handler, which may modify state that the virtual machine does not expect to be modified. The PHP VM plays increasingly complex games to prevent this, but despite all that complexity, this problem cannot be fully solved while this remains a warning, rather than an exception. Same goes for other warnings in the engine of course, undefined variables are just the biggest offender, because this particular warning can occur as part of nearly any operation. The additional complexities that arise when you combine this problem with a JIT compiler are left as an exercise to the reader. Regards, Nikita
