Re: Long-Term Planning for PHP 9.0 Error Promotion

On Fri, Jan 28, 2022 at 3:13 PM Robert Landers <landers.robert@gmail.com> wrote: > I would posit differently. In my experience in upgrading code, it was > mostly intentional. > Here's an example: > > ---- > if($doThing) { > $doOtherThing = maybe(); > } > // later > if($doOtherThing) { > doOtherThing(); > } > --- > > There's no bug here, nothing is unintentional, and the intent is clear. > Now, > if we want to get rid of the warning we need to say $doOtherThing = false > before getting to the first if-statement, but should this halt everything > in > production? I don't personally think so and it would be undesirable for it > to do so. > Let me go over this. > There's no bug here, nothing is unintentional, and the intent is clear I cannot guarantee there's no bug, I cannot guarantee that this is intentional, and the intent is certainly not clear. I can't tell whether or not this code is suffering from a merge conflict, and I cannot guarantee that whatever type maybe(); returns here works. If at some point the return type of null is changed to false, while the assumption of undefined is null, passing false to a nullable typed argument later on will break. > Now, if we want to get rid of the warning we need to say $doOtherThing = false before getting to the first if-statement Thank you for pointing to the example above. null and false are different values. Your assumption here is that setting it to false would fix the problem, but the actual value would've been null and changing it to false might actually break more. > but should this halt everything in production? I don't personally think so and it would be undesirable for it to do so. Any type error should if you ask me. Unexpected types cause unexpected behavior, and the longer PHP will try to continue with assumptions of types and implicit casting, the bigger the damage can be. All this type juggling is headache material and the less I see of it, the better.