Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
September 13, 2019 09:29 (Zeev Suraski)
On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson <>

> "We know it is bad or can be devastating
Actually, that's not at all what we're saying. I think that doing something like @$foo++ is absolutely fine. Many others on this (and related) threads think so too. I find all the 'improvements' with littered questionmarks to be a giant step backwards.
> Why were there notices if something wasn't wrong somewhere with the > behavior? >
We've been through that. You may want to take a look again at the definition of what a notice is. Zeev said the RFC was never meant to deprecate things and as such the
> voting would eventually not pass on to implementation even if it was > accepted - > > "why then do you vote no on the RFC if it was never a valid vote to count?" >
Which is precisely why I didn't vote on that particular part of the RFC so far. That said - I am considering voting a 'keep notice' on it, and I'll briefly explain why. The choice between moving to a warning or keeping a notice is completely legit, and moving it to a warning may even a good idea (mainly due to error reporting defaults, even though a notice is technically more appropriate; main worry is that it might constitute a reason for others in the future to say it's no longer legitimate, and therefore it's no big deal to deprecate it). The part of moving to an error exception is not - as it is a radical change in functionality (and not a simple 'reclassification of errors'), aka deprecation. If I do choose to vote to one of the other two options - it should be taken in the context of choosing between the two valid options, and not as any sort of validation on the invalid one. Zeev