I was really really hoping that we will avert having to dive into this and instead go for the alternative solution that was proposed of changing default php.ini error levels. But since the RFC went on to a vote - we need to make something clear.
The RFC process was never, ever meant to handle fundamental changes to the language. It was meant to deal predominantly with additions to the language, as can be inferred from numerous parts in the phrasing. As I mentioned in the past - it wasn't even intended to deal with simpler deprecations, but it appears that the cat is out of the bag on this one. However, the fact the cat is out, doesn't mean we'll let a tiger waltz out of the same bag. Using the RFC to deprecate fundamental behaviors of the language - such as how the language deals with undefined variables - is simply off the table. You may be wondering, in that case, what processes do we have to deal with such changes then? The answer is simple. We don't. We don't have to have them either - the fundamental language behaviors are here to stay. Deprecating the ability to rely on the expected default value of uninitialized variables falls squarely in that category. Reclassifying a notice to a warning is a possibility - people's code will still run, and they'll be able to continue using these behaviors going forward as well if they want to (perhaps with minor tweaks to error reporting levels). Turning a notice to an error isn't reclassifying an error level. It's deprecating a behavior - and we're not talking about some esoteric extension, but a documented, well-defined, fundamental behavior of the language for over two decades. The fact many of you think it's horrible does not change that. Deprecating such fundamentals is simply outside of the mandate of internals@, regardless of whatever majority appears to exist in favor of it at a given time. Similarly - adding typed variables - is certainly a future option. Changing PHP to require typed variables (without opting in) - is well outside of the internals@ mandate. For areas like that - our options are either doing nothing, or providing opt-in mechanisms to cater to stricter-loving audiences. I'm all for the 2nd option, but there is no 3rd. Zeev
