Re: Changing fundamental language behaviors

On 12/09/2019 16:44, Zeev Suraski wrote:

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.

While I am not sure your tone will be well received by your target audience, I just wanted to say I tend to agree. Breaking BC here does not seem to bring much. If there are cases where enforcing strictness might allow better JIT for example, then I could see the case being made. But simply turning working code into fatally failing code isn't progress. I know I have a bunch of old stuff running which tends to litter the error logs with notices, and I don't have time to go fix them so I ignore because it's fine and it works. For new projects, what I do, and what I am pretty sure 99% of the "strict camp" does is essentially boiling down to:

    set_error_handler(function () { throw new \RuntimeException(); });

That's our global strictness flag right there. It's been available for ages. I don't see why we need to take something away from others to make such an easy workaround a little less needed. Especially as I don't imagine we will drop the error handlers. I sure will keep mine around to keep failing warnings etc as hard fatals. So what do we gain exactly? Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be