Before reading the responses to this thread, I had honestly never encountered a PHP developer who thought using uninitialized variables was fine. I knew it worked, but I always considered this to basically be the PHP equivalent of undefined behavior in C. And I don't think anyone would get mad if a new GCC version broke the way they were abusing UB.
To me and to every developer I've ever known, the only difference between a notice and a warning is the severity of the error. But they're both considered errors - mistakes you made in your code that you need to fix. I'm fairly certain this is how most developers treat them in the real world. Either way, if you want a less strict language, that language already exists: It's the current version of PHP and you and everyone else who likes the way it works can keep using it. Meanwhile, I think most people currently doing serious PHP work would *love* some more strictness and I don't think keeping your old code running on a brand new version of the language is a good enough reason to keep this feature out of 8.0. What's the point of even having major releases if every potential BC break gets shot down by the same 3 people on this mailing list? As for the check engine light analogy, I guess instead of saying "this is fine", you just smash your entire dashboard with a hammer to make the problem go away. Because that's what using @ or error_reporting does. I hope this RFC passes, but I don't see any point in discussing it further here, so I'll go back to lurking now. On 29.08.2019 16:22, Zeev Suraski wrote: > > > On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals > <internals@lists.php.net <mailto:internals@lists.php.net>> wrote: > > I know what the manual says about notices. But I don't agree with > interpreting "could happen in the normal course of running a > script" as "it's perfectly fine if this part of your code triggers > a notice consistently and every time it goes down this particular > code path". Rather, I've always interpreted this as "under > certain, rare, unforeseen circumstances, your code could generate > a notice here, probably because of something that is outside of > your control". > > That's how I've always treated them at least. > > > And that's entirely within your right to do so - but what the manual > says is accurate. Calling me delusional in my interpretation of it is > somewhat awkward (to put it mildly), I have a pretty good idea of why > we added the different error levels - I wrote much of it myself. > > The whole point of having notices as something that's separate from > warnings is that they have different semantics, and that semantics is > captured very accurately in the manual. They are used to mark issues > which may be problems, but may also be perfectly fine (unlike > warnings, which generally speaking mean that something bad happened, > but not bad enough to halt execution). Notices were meant to help you > implement a more strict style of coding, and they may help you catch > certain types of bugs, but you can have perfectly working, bug-free > code that generates notices. > > Regardless of the exact semantics, don't you think a program that > generates a constant stream of notices is a bit strange? That > sounds like something everyone would naturally want to avoid. You > don't drive your car with the check engine light permanently on > and say "this is fine", right? > > > Except you can purposely turn off this 'check engine' light, never to > see it again if you choose to. And that it's really not at all > similar to 'check engine', but a lot closer to 'check cleaning fluid', > or even 'clean windshield' (if cars had a dashboard light for that). > Even that is not a good analogy - as folks often actually purposely > write code that generates notices (which would be purposely hidden, > either by error_reporting setting or using @) that is 100% bug-free > and working as intended. So no, there's nothing strange about it if > you buy into that approach. If you don't (and I know you don't) - > that's absolutely fine - it's up to you. > > Zeev >
